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This  thesis  presents  an  algebraic  specification 
technique  that  overcomes  these  problems.  It  is  derived  from 
Poare’s  work  on  the  axiomatic  specification  of  the  semantics 
of  programming  languages,  and  from  Birkhoff  and  Lipson's 
heterogeneous  algebras.  An  algebraic  specification  of  an 
abstract  data  type  consists  of  two  parts:  a  syntactic 
specification  and  a  set  of  relations.  The  syntactic 
specification  provides  the  names,  ranges,  and  domains  of  the 
operations  associated  with  the  type.  The  relations  define 
the  meaning  of  the  operations  by  stating  their  relationships 
to  one  another. 


The  prime  difficulty  in  constructing  algebraic 
sp®ci f icat ions  of  abstract  data  types  lies  in  ascertaining 
whether  or  not  a  specification  is  sufficient  to  fully  define 
the  type.  For  this  reason,  a  mechanical  technique  for 
verifying  the  sufficienr-completeness  of  certain  classes  of 
algebraic  specifications  has  been  devised. 


Other  discussions  include  a  treatment  of  some  of 
theoretical  properties  of  the  specification  techni 
presented,  and  discourses  on  the  application  of 
algebraic  specification  of  abstract  data  types  to  top-d 
program  design  and  program  verification. 
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1.  An  introduction  to  the  problem 

1.1.  The  milieu 

The  function  of  a  program  is  to  provide  an  executable 
embodiment  of  an  abstract  solution  to  a  problem. 
Programming,  then,  is  the  process  of  transforming  the 
abstract  to  the  executable.  Years  of  experience  have  taught 
us  that  the  best  way  to  do  this  is  through  a  hierarchy  of 
small  refinements  (see,  for  example,  Dijkstra  f  1972  ]). 
Thus,  though  one’s  final  goal  is  a  concrete  implementation 
of  a  solution,  one  still  works  primarily  with  abstractions. 
It  is  therefore  crucial  that  the  programmer  have  at  his 
disposal  suitable  tools  for  dealing  with  abstraction. 

Abstraction  may  be  said  to  be  the  process  of  forming  a 
concept  or  idea  by  imaginatively  isolating  or  considering 
apart  the  common  characteristics  of  a  group  of  distinct 
objects  or  events.  As  such,  a  judiciously  chosen 
abstraction  serves  to  separate  those  attributes  of  an  object 
or  event  that  are  relevant  in  a  particular  context  from 


those  that  are  not 
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Ori€  of  the  most  significant  aids  to  abstraction  used  in 
programming  is  the  self-contained  subroutine.  At  the  point 
where  one  decides  to  invoke  a  subroutine,  one  may  (and  most 
often  should)  treat  it  as  a  "black  box.”  It  performs  a 
specific,  arbitrarily  abstract,  function  by  means  of  an 
unprescribed  algorithm.  Thus,  at  the  level  where  it  is 
invoked,  it  separates  the  relevant  detail  of  "what,"  from 
the  irrelevant  detail  of  "how."  Similarly,  at  the  level 
where  it  is  implemented,  it  is  usually  unnecessary  to 
complicate  the  "how"  by  considering  the  "why,"  i.e.,  the 
exact  reasons  for  invoking  a  subroutine  need  not  be  of 
concern  to  its  implementor.  Ey  nesting  subroutine 
invocations,  one  may  develop  a  hierarchy  of  abstractions. 

Unfortunately,  the  nature  cf  the  abstractions  that  may 
be  conveniently  achieved  through  the  use  of  subroutines  is 
limited.  Subroutines,  while  well  suited  to  the  description 
of  abstract  events  (operations) ,  are  not  particularly  well 
suited  to  the  description  of  abstract  objects.  This  is  a 
serious  drawback,  for  in  a  great  many  applications  the 
complexity  of  the  data  objects  to  be  manipulated  contributes 
substantially  to  the  overall  complexity  of  the  problem. 
How,  then,  might  one  go  about  abstracting  data?  An 
important  step  is  the  separation  of  those  details  that  are 
relevant  at  a  given  level  of  abstraction  from  those  that  are 
not.  This  can  be  a  difficult  endeavor,  for  there  are  few 
hard  and  fast  distinctions  by  which  to  be  guided.  There 

a  few  widely  (but  not  universally)  used 


are,  however. 
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distinctions  that  often  prove  useful.  (See  [Tompa  1975]  for 
a  slightly  different,  but  compatible,  set  of  distinctions.) 

It  is  often  useful  to  distinguish  between  data  (or 
information)  structures  and  storage  structures  [d*Imperio 
1969].  A  storage  structure  describes  the  manner  in  which 
data  is  laid  out  in  storage:  either  the  physical  store 
defined  by  the  hardware,  or  an  abstract  store  defined  by  a 
combination  of  hardware  and  software  (e.g.,  a  programminq 
language  or  a  virtual  memory).  The  term  data  structure,  on 
the  other  hand,  refers  to  the  "meaning"  of  the  data.  That 
is  to  say,  it  deals  with  how  the  data  is  to  be  interpreted. 
An  example  may  help  to  clarify  this  distinction.  The  four 
contiguous  cells 

i_3_l  I_2_J  1_1_1 

may  be  thought  of  as  forming  a  primitive  storage  structure. 
The  meaning  of  that  structure,  however,  is  dependent  solely 
upon  the  use  one  makes  of  the  information  contained  in  those 
cells,  i.e.,  the  integers  5,  3,  2  and  1.  They  might,  for 
example,  be  construed  as  representing  the  polynomial 
5 x3  +  3x2-f 2x+ 1 .  On  the  other  hand,  one  might  think  of  the 
storage  structure  as  representing  the  polynomial  5x3+2x,  or 
even  the  integer  5321.  Clearly,  a  single  storage  structure 
may  prove  suitable  for  representing  a  myriad  of  data 
structures.  Similarly,  for  any  data  structure,  there  are 
many  possible  storage  structures.  The  distinction  between 
data  and  storage  structures  is  not  a  rigid  one.  It  depends 
upon  one's  current  level  of  abstraction. 
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It  is  also  possible  to  make  a  distinction  between  a  data 
structure  and  a  data  type,  A  data  type  may  be  thought  of  as 
defining  a  named  class  of  operands  (i.e.,  a  set  of  primitive 
values  that  are  manipulated  as  indivisible  units),  e. g. r 
type  Integer.  In  contrast  to  this,  a  data  structure  defines 
a  class  of  aggregations  of  values,  where  the  members  of  each 
aggregation  may  be  accessed  and  manipulated  as  individuals, 
Peturning  to  the  polynomial  example,  when  Polynomial  is 
viewed  as  a  data  type,  the  multiplication  of  Polynomials  p 
and  q  is  naturally  written  as  pq.  When  Polynomial  is  viewed 
as  a  data  structure,  however,  multiplication  is  more 
naturally  denoted  in  terms  of  operations  on  the  individual 
exponents  and  coefficients.  As  with  the  distinction  between 
storage  and  data  structures,  the  distinction  between  data 
structures  and  data  types  depends  upon  the  current  level  of 
abstraction.  Consider,  for  example,  arrays.  The  operation 
A  (I): =3  may  be  viewed  as  an  operation  upon  the  array  element 
A  (I)  [Batey  1973  ]  or  as  an  operation  upon  the  entire  array  A 
[ Hoare  1973],  In  the  former  case.  Array  would  be  called  a 
data  structure,  and  in  the  latter,  a  data  type. 

Data  types,  data  structures,  and  storage  structures  all 
play  important  roles  in  the  programming  process.  Their 
respective  rcles  are  parricularly  clear  and  well-defined  in 
the  process  of  programming  by  successive  refinement  [Wirth 
1971],  This  process  consists  of  the  generation  of  a 
sequence  of  refinement  steps.  In  each  step  an  operation  or 
object  is  defined  in  terms  of  a  number  of  sub-operations  or 
sub-objects.  The  process  terminates  when  all  such  sub- 
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tions  and  sub-objects  are  fully  defined  in  terms  that 
eaningful  to  the  hardware  or  software  environment  in 
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acted  graph  g1  and  a  node  v1  of  that  graph,  list  the 
that  belong  to  the  same  connected  component  as  v1. 


We  begin  with  a  refinement  based  upon  the  depth  first 
search  technique  of  Tarjan  [1972]. 


search:  £rocsdure  (v,g)  recursive 

visited  :=  add  (visited, v) 
out£ut  : =  V 

do  for  n  :=  each  node  of  g  adjacent  to  v 
if  -•  (nevisited) 

then  search  (n,g) 

end 

visited  :=  f  } 
searc  h  (v1  ,g1) 
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change  of  state  may  be  represented  as  the  assignment  of  a 
new  value  to  a  variable. 


Were  one  to  proceed  to  refine  the  above  solution,  one 
would  eventually  be  forced  not  only  to  supply 
implementations  for  the  operations  introduced  (e.g.,  "add" 
and  "each  node  of  g  adjacent  to  v") ,  but  also,  in  parallel, 
a  storage  structure  for  values  of  types  Set  and  Graph.  Thus 
the  representation  of  a  data  type  includes: 


1)  a  storage  structure, 

2)  a  set  of  operations  for  creating,  destroying, 

modifying,  and  examining  that  structure,  and 

3)  an  interpretation  of  the  storage  structure,  i.e.  ,  a 
mapping  from  its  values  to  values  of  the  abstract  data  type. 

The  implementation  of  the  operations  is  governed  largely  by 
the  choice  of  storage  structure  --  a  matter  which  is  not 
dealt  with  in  this  thesis.  A  poor  choice  of  storage 
structure,  e.g.,  using  an  adjacency  matrix  to  represent 
values  of  type  Graph,  may  have  a  severely  deleterious  effect 
on  the  efficiency  of  implementations  of  the  operations. 
Choosing  a  storage  structure  wisely  is,  therefore,  a  matter 
of  extreme  importance.  It  is  also  a  matter  of  substantial 
difficulty.  Cne  mus+  take  into  account  a  large  number  of 
factors,  including  at  least;  the  storage  medium  to  be  used, 
the  operations  to  be  applied  to  the  structure,  the  relative 
frequencies  of  these  operations,  and  the  relative  importance 
cf  conserving  time  and  space. 
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1.2.  The  problem 

The  concluding  chapter  of  [Dijkstra  1975]  asserts  that, 
"To  my  taste  the  main  characteristic  of  intelligent  thinking 
is  that  one  is  willing  and  able  to  study  in  depth  an  aspect 
of  one's  subject  matter  in  isolation...  all  the  time 
knowing  that  one  is  occupying  oneself  with  only  one  of  the 
aspects..,.  The  crucial  choice  is,  of  course,  what  aspects 
to  study  in  'isolation,'  how  to  disentangle  the  original 
amorphous  knot  of  obligations,  constraints,  and  goals  into  a 
set  of  'concerns'  that  admit  a  reasonably  effective 
separation."  P.s  suggested  in  the  preceding  section,  the 
large  "knot"  of  complexly  interrelated  attributes  associated 
with  a  data  object  may  be  separated  according  to  the  nature 
of  the  information  that  the  attributes  convey  regarding  the 
objects  that  they  qualify.  Two  kinds  of  attributes,  each  of 
which  may  be  studied  in  "isolation"  are; 

1)  those  that  describe  the  representation  of  objects  and 
the  implementations  of  the  operations  associated  with  them 
in  terms  of  other  objects  and  operations,  e.g.,  in  terms  of 
a  physical  store  and  a  processor's  order  code, 

2)  those  that  specify  the  names  and  define  the  abstract 
meanings  of  the  operations  associated  with  an  object. 

Though  these  two  kinds  of  attributes  are  in  practice  highly 
interdependent,  they  represent  logically  independent 
concepts . 
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The  first  of  these  is  clearly  related  to  the  problem  of 
choosing  a  storage  structure  —  a  problem  that  is  not 
discussed  in  this  thesis.  Good  discussions  of  this  problem 
are  contained  in  [Cardenas  1973]  and  [Tompa  1974].  Cardenas 
concentrates  mainly  on  the  problem  of  choosing  a  storage 
structure  for  a  two- level  store.  Tompa,  on  the  other  hand, 
confines  his  discussion  (which  is  considerably  more  detailed 
than  that  of  Cardenas)  to  storage  structures  for  single- 
level  stores. 

Ths  emphasis  in  this  thesis  is  on  the  specification  of 
the  operations  associated  with  classes  of  data  objects.  At 
most  points  in  a  program  one  is  concerned  solely  with  the 
behavioural  characteristics  of  a  data  object.  One  is 
interested  in  what  one  can  do  with  it,  not  with  how  the 
various  operations  on  it  are  implemented.  The  analogy  with 
a  closed  procedure  is  exact.  More  often  than  not,  one  need 
be  no  more  concerned  with  the  relationship  to  underlying 
store  of  the  object  being  operated  upon,  than  one  is  with 
the  algorithm  used  to  implement  an  invoked  procedure. 

If  at  a  given  level  of  refinement  one  is  interested  only 
in  the  behavioural  characteristics  of  certain  data  objects, 
then  any  attempt  to  abstract  data  must  be  based  upon  those 
characteristics,  and  only  those  characteristics.  The 
introduction  of  other  attributes,  e.g.,  a  representation, 
can  only  serve  to  cloud  the  relevant  issues.  I  will  use  the 
term  "abstract  data  type"  to  refer  to  a  class  of  objects 
defined  by  a  representation-independent  specification. 
There  are  two  distinct  problems  associated  with  the 
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d^finition  of  abstract  data  types.  I  shall  call  one  the 
"language  design  problem,"  and  the  other  the  "type 
specification  problem." 

The  language  design  problem,  which  is  not  dealt  with  in 
this  thesis,  is  to  find  acceptable  ways  to  embed  the  concept 
of  an  abstract  data  type  in  programming  languages.  Strictly 
speaking,  it  is  possible  to  use  abstract  data  types  as  a 
programming  tool  without  actually  making  provision  for  them 
in  the  programming  language.  There  are,  however,  several 
advantages  to  be  gained  from  having  a  facility  for  the 
definition  of  abstract  types  available  within  a  programming 
language.  Perhaps  the  most  significant  of  these  is  that  it 
increases  the  likelihood  that  the  program  text  will 
accurately  reflect  the  abstract  logic  of  the  program.  That 
is  to  say,  the  program  is  more  likely  to  reflect  the  thought 
processes  that  led  to  its  construction.  Thus  the  program 
should  be  easier  to  read  and  comprehend,  particularly  for 
those  who  were  not  involved  in  its  construction.  The 
provision  of  a  facility  for  explicitly  including  abstract 
type  definitions  in  the  program  text  should  also  eliminate 
much  of  the  need  for  external  documentation,  e.g.,  four- 
colour  diagrams  to  explain  how  a  host  of  declarations  and 
procedures  are  combined  to  form  one  data  structure.  This 
would  be  a  significant  accomplishment,  largely  because  such 
descriptions  almost  invariably  become  outdated  and  therefore 
misleading. 

A  second  reason  for  the  inclusion  of  facilities  for  the 
definition  of  abstract  data  types  within  programming 
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lanquages  is  to  permit  type  checking.  Much  has  been  written 
about  the  benefits  to  be  gained  from  extensive  type 
checking.  [Gannon  1975]  and  [Morris  1973]  contain 
particularly  good  discussions.  Morris  suggests  that  type 
checking  serves  two  distinct  purposes:  authentication  and 
secrecy.  Ey  authentication,  he  means  that  type  checking  can 
be  used  to  prevent  programs  from  attempting  to  perform 
operations  on  values  of  other  than  the  appropriate  type; 
trying  to  divide  one  queue  by  another,  for  example.  What 
Morris  calls  secrecy  has  often  been  called  protection  or 
security.  Its  purpose  is  to  prevent  users  from  writing 
programs  that  depend  upon  the  particular  representation 
chosen  for  a  type.  If  one  can  actually  define  a  type  Stack, 
rather  than  a  data  structure  to  be  used  as  a  stack,  then  the 
user  can  be  prevented  from  modifying  or  accessing  stack 
values  except  through  the  operations  provided  as  part  of  the 
type.  This  inhibits  him  from  destroying  the  integrity  of 
the  data  structure,  and  from  writing  programs  that  may 
preclude  a  redesign  of  the  representation  for  the  type. 


Ealzer  [1967]  was  one  of  the  first  to  recognize  the 
advantages  to  be  gained  from  providing  a  mechanism  for  the 
definition  of  abstract  types  (though  he  did  not  use  that 
term)  .  He  suggests  that  a  program  should  be  viewed  '’as  the 
specification  of  a  set  of  manipulations  to  be  performed  on  a 
set  of  data  values,  and  that  this  specification  should  be 
independent  of  the  form  in  which  these  data  values  are 
represented,"  He  proposed  an  extension  to  PL/I  as  a  vehicle 
for  accomplishing  this.  The  proposal  contained  some 


-11- 


ir.teresting  ideas,  but  failed  to  overcome  some  of  the  basic 
problems  that  PL/I  presented  as  a  host  language.  It  was, 
for  example,  impossible  to  attain  a  suitable  level  of  type 
checking. 

The  class  construct  of  SIMDLJ^.  67  [Dahl  1968]  has  been 
used  as  the  starting  point  for  much  of  the  more  recent  work 
on  embedding  abstract  types  in  a  programming  language,  e. g. , 
[Morris  1973],  [Liskov  1974],  [Wulf  1974],  and  [Palme  1973]. 
Pach  of  these  efforts  has  something  distinctive  to  recommend 
it,  but  none  of  them  seems  to  represent  a  major  departure 
from  the  original  class  concept.  A  rather  different 
approach  to  data  types  is  represented  by  the  mode 
definitions  of  ALGOL  68  [van  Wijngaarden  1969].  This 
approach,  however,  seems  to  have  had  substantially  less 
impact  on  current  work  in  the  area  of  abstract  data  types 
than  has  SIMULA  67.  A  comparison  of  these  two  approaches  is 
contained  in  [Flon  1974].  "Extensible  languages"  represent 
a  third  stream  of  work  in  this  area.  In  most  extensible 
languages  the  data  (or  data  type)  definition  facilities  are 
patterned  after  the  facility  described  in  [ Standish  1969]. 
In  essence,  this  approach  is  very  close  to  that  of  ALGOL  68. 
ELI  [Wegbreit  1973]  captures  the  notion  of  data  abstraction 
a  bit  more  directly.  Through  the  interactive  facilities  of 
the  language  and  its  approach  to  delayed  binding,  levels  of 
abstraction  of  modes  may  be  easily  defined  and  traversed. 

None  of  these  efforts  were  oriented  towards  the  type 
specification  problem.  While  each  offers  a  mechanism  for 
binding  together  the  ope ratio ns  and  storage  structures 
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representing  a  type,  they  offer  no  representation- 
independent  means  for  specifying  the  behaviour  of  the 
operations.  The  only  representation-independent  information 
that  one  can  supply  are  the  domains  and  ranges  of  the 
various  operations.  One  could,  for  example,  define  a  type 
Queue  (of  Integers)  with  the  operations 
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There  have  been  a  number  of  extra-programming  language 
attempts  to  deal  with  the  type  specification  problem. 
Unfortunately,  for  reasons  which  are  outlined  in  Chapter  2, 
ncne  of  them  has  been  completely  successful.  This  thesis 
presents  and  discusses  the  applications  of  a  technique  that 
offers  significant  advantages  over  these  other  approaches  to 
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the  representation-f ree  specification  of  abstract  data 
types.  More  specifically,  the  contributions  of  this  thesis 
are: 

•  suggesting  a  formal  framework,  heterogeneous  algebras, 
in  which  the  concept  of  an  abstract  data  type  may  be 
profitably  studied, 

•  supplying  a  technique,  algebraic  specification,  for 
the  specification  of  abstract  data  types, 

•  providing  a  computationally  feasible  method  for 
demonstrating  the  sufficiency  of  a  specification, 

•  showing  how  abstract  data  types  and  their  algebraic 
specifications  can  be  used  in  concert  with  other  techniques 
to  facilitate  the  specification,  design,  and  implementat ion 
cf  software, 

•  providing  a  formal  definition  of  the  correctness  of 
implementations  of  abstract  data  types,  and  illustrating  how 
an  implementation  may  be  proved  to  be  correct  with  respect 
to  such  a  definition. 
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1.3.  The  organization  of  the  thesis 

This  thesis  contains  two  kinds  of  material.  Chapter  3 
is  theoretically  oriented  and  somewhat  formal,  while 
chapters  1,  2,  and  4-6  are  more  practically  oriented,  and 
together  form  an  almost  self-contained  treatise. 

Chapter  2  explores  the  importance  of  abstraction  and 
formal  specification,  and  explains  why  the  technigues 
currently  available  are  inadequate  for  the  specification  of 
data  abstractions.  This  chapter  also  includes  an  informal 
description  of  algebraic  specification  and  a  shcrx 
discussion  of  some  of  the  advantages  and  problems  of  this 
approach  to  the  specification  of  abstract  data  types. 
Chapters  4  and  5  discuss  and  illustrate  via  substantial 
examples  the  application  of  abstract  types  to  proofs  of 
correctness  and  the  design  of  software.  Chapter  6  concludes 
the  dissertation  with  an  evaluation  of  the  work  presented,  a 
discussion  of  its  practical  applications,  and  some 
suggestions  for  future  research  in  this  area. 

Chapter  3  provides  the  theory  behind  the  algebraic 
specification  of  abstract  data  types.  It  presents  a  formal 
definition  of  abstract  types  as  a  restricted  class  of 
heterogeneous  algebras,  and  contains  rather  detailed 
discussions  both  of  the  problems  involved  in  demonstrating 
the  sufficiency  of  a  specification  and  of  some  techniques 
for  attacking  these  problems,  Although  the  typical  user 
need  not  be  concerned  with  the  details  of  how  it  has  been 
established,  the  practical  application  of  these  technigues 
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2.  An  introduction  to  the  specification  and  use  of  abstract 
data  types 

The  body  of  this  thesis  deals  with  a  particular 
technique  for  the  formal  specification  of  abstract  data 
types.  This  chapter  is  intended  to  serve  as  an  introduction 
to  that  technique.  Section  2.1.  contains  a  brief  discussion 
of  the  role  played  by  formal  specification  in  the 
proqramminq  process.  Section  2.2.  beqins  with  a  look  at 
what  constitutes  a  good  specification,  and  then  continues 
with  a  discussion  of  the  attributes  that  make  a 
specification  technique  well-suited  to  the  construction  of 
such  specifications.  The  section  concludes  with  a  review  of 
some  of  the  specification  techniques  in  use  today,  and  a 
short  description  of  the  algebraic  specification  technique 
to  be  presented  in  this  thesis.  The  technique  is  informally 
described  in  Section  2.3,  which  also  includes  some  sample 
specifications,  and  a  discussion  of  the  strengths  and 
weaknesses  of  the  proposed  technique.  The  formal 
development  of  the  specification  technique  is  reserved  for 
Chapter  3. 
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2.1,  The  role  cf  formal  specification  in  programming 

In  a  study  cited  in  [Boehm  1975]  64%  of  all  errors  and 
over  83%  of  those  errors  found  during  or  after  the 
acceptance  test  of  a  large  ("100,000  source  statements") 
piece  of  software  were  attributable  to  design-related 
causes.  The  dominant  causes  cited  were  "interface 
inconsistencies,  incomplete  problem  statements,  ambiguous 
specifications,  or  inconsistent  assumptions."  Errors  of 
these  kinds  can  be  introduced  into  a  software  project  either 
through  an  error  in  the  thought  processes  of  an  individual, 
or  through  a  breakdown  in  communication  among  a  number  of 
individuals. 

Dijkstra  [1972]  and  many  others  have  made  the  poinr  that 
the  amount  of  complexity  that  the  human  mind  can  cope  with 
at  any  instant  in  time  is  considerably  less  than  that 
embodied  in  much  of  the  software  that  one  might  wish  to 
build.  The  key  problem  in  the  design  of  large  software 
systems,  and  thus  (as  a  corollary  to  the  statistics  cited 
above)  the  key  to  reducing  the  number  of  mistakes  committed, 
is  reducing  the  amount  of  complexity  or  detail  that  must  be 
considered  at  any  one  time.  Dahl  [1970]  cites  "two 
fundamental  principles  of  thought"  involved  in  this  process: 
"decomposition"  and  "classification." 

One  decomposes  a  task  by  factoring  it  intc  two  or  mere 
separable  sub-tasks.  Unfortunately,  for  many  problems  the 
separable  sub-tasks  are  still  too  complex  to  be  mastered  in 
tpto.  The  complexity  of  this  sort  of  problem  must  be 
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reduced  via  what  Dahl  called  "classification”  —  a  process 
that  today  is  more  commonly  known  as  abstraction.  As 
suggested  in  Section  l.lr  by  providing  a  mechanism  for 
separating  those  attributes  of  an  object  or  event  that  are 
relevant  in  a  given  context  from  those  that  are  not, 
abstraction  serves  to  reduce  the  amount  of  detail  that  one 
need  come  to  grips  with  at  any  one  time. 

If  one  is  to  make  full  use  of  abstraction,  the 
availability  of  a  good  notation  for  expressing  abstractions 
is  critical.  It  is  obvious  that  a  reasonable  language  is  a 
prereguisite  to  the  communication  of  something  as  intangible 
as  an  abstraction.  It  is  less  obvious,  but  equally  true, 
that  a  reasonable -language  is  a  prerequisite  to  the  creation 
of  such  abstractions.  If  the  availability  of  a  language  is 
not  necessary  for  the  initial  formulation  of  an  abstraction 
(an  argument  I  leave  to  psychologists  and  linguists) ,  it  is 
certainly  necessary  if  the  abstraction  is  to  be  retained  and 
developed  over  any  significant  period  of  time.  An  informal 
language,  such  as  a  natural  language,  is  not  always 
efficient  —  either  for  the  communication  of  abstractions  or 
for  their  creation.  (This  is  not  to  say  that  informality 
has  no  role  to  play  in  the  abstraction  process.  At  times 
the  high  intuitive  content  of  informal  language  makes  it  a 
valuable  tool  for  both  creative  thinking  and  the 
communication  cf  the  fruits  of  that  thought.) 

Unlike  formal  languages,  informal  languages  do  not  force 
precision.  In  fact,  it  is  only  by  dint  of  great  care  and 
expertise  that  it  is  possible  to  write  precise 
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specifications  in  a  notation  as  informal  as  a  natural 
language.  Thus,  at  times,  an  informal  language  may  prove 
more  a  hindrance  than  a  help  in  organizing  one's  thoughts. 
The  problem  is  compounded  when  one  attempts  to  use  an 
informal  notation  as  a  mechanism  for  communicating  an 
abstraction  to  others.  Not  only  might  the  specification  be 
underdefined,  hence  ambiguous,  bur  the  very  language  in 
which  the  specification  is  stated  will  almost  certainly  be 
ambiguous.  If  all  goes  well,  someone  will  perceive  the 
ambiguity,  and  it  will  be  resolved.  Mors  often,  the  people 
involved  will  merely  form  their  own,  different,  conceptions 
of  the  abstraction,  leading  to  the  interface  problems 
already  mentioned. 

Of  course,  the  use  of  a  formal  language  is  no  guarantee 
that  specifications  will  be  unambiguous  or  even  consistent. 
It  is,  for  example,  quite  possible  to  specify  ambiguous 
grammars  or  empty  languages  in  BNF  [Backus  1959].  What  a 
formal  language  does  provide  are  objective  criteria  for 
recognizing  ambiguity  and  inconsistency,  thus  increasing  the 
likelihood  that  such  failings  in  a  specification  will  be 
recognized.  In  many  cases  formal  specifications  may  also  be 
mechanically  checked  for  completeness  (hence  lack  of 
ambiguity)  and  consistency. 
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2.2.  A  look  at  formal  specification  techniques 

A  good  formal  specification  technique  is  a  technique 
that  facilitates  the  production  of  good  formal 
specifications.  Good  specifications  may  take  many  forms, 
but  all  of  them  have  certain  attributes  in  common.  A  good 
specification  must  be  restrictive  enough  to  ensure  that 
nothing  unacceptable  to  the  specifier  will  meet  the 
specif icaxion.  Yet  it  must  also  be  sufficiently  general  to 
ensure  that  few  (if  any)  acceptable  entities  are  precluded. 
And  finally,  a  good  specification  must  be  perspicuous 
enough,  i.e.,  plain  enough  to  the  understanding,  to  permit  a 
high  degree  of  confidence  in  its  aptness. 

That  a  good  specification  must  be  sufficiently 
restrictive  (or  specific)  is  a  statement  that  should  need  no 
justification.  It  is  the  assumption  that  lies  at  the  base 
of  most  of  the  arguments  in  favour  of  formal  specifications 
advanced  in  the  previous  section.  The  importance  of  the 
generality  criterion  is  less  obvious.  It  is  not  essential 
to  ensure  that  no  acceptable  program  is  precluded,  but 
whenever  cne  introduces  unnecessary  constraints,  one  runs 
the  risk  of  eliminating  some  of  the  more  desirable  (e.  g. , 
more  efficient)  solutions  to  the  problem  at  hand.  The 
importance  of  the  perspicuity  requirement  is  often  under¬ 
estimated.  A  specification  is  a  statement  of  intent,  an 
attempt  to  capture  a  concept  that  exists  only  in  someone’s 
mind.  While  there  are  formal  criteria  for  judging  the 
completeness  and  consistency  of  a  specification,  there  can 
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b€  no  formal  method  for  judging  its  suitability.  Therefore, 
it  is  essential  that  a  specification  be  easily  comprehended, 
so  than  one  can  study  it  and  judge,  with  some  amount  of 
confidence,  whether  or  not  it  actually  captures  the  concept 
that  one  had  in  mind. 

There  are  many  formal  specification  technigues  in  use 
today.  Each  has  its  own  strengths  and  weaknesses.  To  a 
large  extent,  the  choice  of  a  specification  technigue 
depends  upon  the  application.  As  stated  above,  an  important 
application  for  programmers  is  the  specification  of 
abstractions.  Liskov  and  Zilles  [Liskov  1975]  isolate  two 
major  classes  of  abstraction:  functional  abstraction  and 
data  abstraction.  In  functional  abstraction,  a 
parameterired  expression  or  collection  of  statements  is 
treated  as  a  single  operation.  Such  an  abstraction  is  most 
often  specified  as  a  relation  between  input  values  and 
output  values. 


In  data  abstraction,  a  nu 


are  grouped  together. 

The  cl 

by  the  fact  that 

they,  a 

particular  class  or 

type  of 

abstractions  are: 

a  symbol 

relational  data  base. 

Promi 

include  Naur  [1969], 

Hoare  a 

McKeeman  [  1975],  and 

Morris  [ 

kind  of  abstraction. 

which  ha 

.  2)  , 


mber  of  functional  abstractions 
ustered  operations  are  related 
nd  only  they,  operate  on  a 
object.  Some  typical  data 
table,  a  priority  queue,  and  a 
nent  exponents  of  their  use 
nd  Dahl  [  1972  ],  Parnas  [  1972a], 
1973].  Specification  of  this 
s  come  to  be  called  an  abstract 
must  deal  with  the  relations 


data  type  (see  Section  1 
among  the  operations. 


Becently  a  considerable  amount  of 


-22- 


attention  has  been  devoted  to  the  development  of  techniques 
for  the  specification  of  data  abstractions,  c.g.,  [Guttag 
1974]  and  [Zilles  1975],  and  this  is  the  principal  topic  of 
this  thesis. 

There  are,  of  course,  many  possible  approaches  to  the 
formal  specification  of  abstract  data  types.  Host,  however, 
can  be  placed  in  one  of  two  categories:  operational  or 
definitional.  In  an  operational  specification,  instead  of 
tryinq  to  describe  the  properties  of  the  abstract  data  type, 
one  gives  a  recipe  for  constructing  it.  One  begins  with 
some  well-understood  language  or  discipline  and  builds  a 
model  for  the  type  in  terms  of  that  discipline. 

The  operational  approach  to  formal  specification  has 
many  advantages.  Most  significantly,  operational 
specifications  seem  to  be  relatively  (compared  to 
definitional  specifications)  easily  constructed  by  those 
trained  as  programmers  --  chiefly,  because  the  ccnstruction 
of  operational  specifications  so  closely  resembles 
programminq.  For  abstract  types  containing  a  small  number 
of  moderately  simple  operations,  operational  specifications 
seem  to  offer  a  sufficient  degree  of  perspicuity.  Earley's 
two-dimensional  representation  [Earley  1971]  is  particularly 
effective  in  this  respect.  As  the  operations  to  be 
specified  grow  more  complex,  however,  operational 
specifications  tend  to  get  too  long  (see,  for  example, 
[  Eatey  1973])  to  permit  substantial  confidence  in  their 
aptness.  As  the  number  of  operations  grows,  problems  arise 
because  the  relations  among  the  operations  are  not 
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explicitly  stated,  and  inferring  them  becomes 
combinatorially  harder. 

The  most  serious  problem  associated  with  operational 
specifications  is  that  they  almost  always  force  one  tc 
overspecify  the  abstraction.  Ey  introducing  extraneous 
detail  they  associate  non-essential  attributes  with  the 
type.  Consider,  for  example,  type  Stack  (of  Integers)  with 
operations  NEWSTACK,  POSH,  POP,  and  TOP.  An  operational 
specification  might  look  something  like: 


STACK 


declare  1.  STACKELEM, 

2.  PBEV  reference  to  STACKELEM, 

2.  VALUE  integer. 

NEWSTACK  returns  (reference  to  STACKELEM) 

(nil) 

end 

nisnnlnii  PUSH  (S : reference  to  STACKELEM,  l^inte^er) 

returns  (reference  to  STACKELEM) 
allocate  STACKELEM'set  (NEH_s7 

NEW_S->PEEV  :=  S 

NEW_S->VALUE  :=  I 

return  (NEW_S) 

end 

procedure  POP  (S : reference  to  STACKELEM) 

returns  (reference  to  STACKELEM) 
if  S  =  nil 

t h£n  error 

else  CLD_S  :=  S->PREV 

free (S->STACKELEM) 
return (OLD_S) 

end 

procedure  TOP  (S: reference  to  STACKELEM)  returns  (integer) 
if  S  =  nil 
then  error 

else  return (S->VALUE) 


-25- 


To  accept  this  specification  as  the  definition  of  type 
Stack  is  to  conclude  that  a  stack  is  a  last-in-first-out 
one-way  linked  list  of  integers.  Clearly,  this  is  an 
unnecessarily  restrictive  definition  of  the  type.  The 
notion  of  a  one-way  linked  list  has  nothing  to  do  with  the 
abstract  notion  of  a  stack;  it  has  to  do  only  with  a 
particular  iirplementation  of  that  notion. 

Extraneous  detail  complicates  the  problem  of  proving  the 
correctness  of  an  implementation  by  introducing  conditions 
that  are  irrelevant,  yet  nevertheless  must  be  verified. 
Mere  importantly,  the  introduction  of  extraneous  detail 
places  unnecessary  constraints  on  the  choice  of  an 
iirplementation,  and  may  potentially  eliminate  the  best 
solution  to  the  problem.  Consider,  for  example,  type 
Integer.  If  one  were  to  provide  an  intuitive  operational 
specification  of  multiplication  (e.g.,  the  algorithm  one 
learns  in  grade  school)  ,  one  would  almost  certainly  have 
limited  oneself  to  order  n^  implementations.  "Eetter" 
implementations  ([Cook  1966  ],  [Schonhage  1971])  would  have 
been  effectively  precluded. 

The  extent  to  which  an  operational  specification  is 
unnecessarily  restrictive  depends  upon  the  level  of 
abstraction  achieved  by  the  specification.  The  level  of 
abstraction  achieved  depends  largely  upon  the  level  of 
abstraction  of  the  language  or  discipline  in  which  the 
specification  is  given.  A  Pl/I  implementation  of  an 
abstract  data  type,  for  example,  scarcely  qualifies  as  an 
abstract  specification.  The  Vienna  Definition  Language 
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([ Lucas  1968],  [Wegner  1972])  allows  considerably  more 
abstract  definitions.  Earley’s  V-graphs  [Earley  1971]  and 
Parnas's  state  machine  model  [ Parnas  1972a]  seem  to  allow 
still  higher  levels  of  abstraction.  As  [ Liskov  1975]  points 
out,  however,  even  these  are  not  sufficiently  abstract  to 
escape  the  problems  associated  with  operational 
specifications. 

In  a  definitional  specification,  one  explicitly  lists 
properties  that  the  values  and  operations  forming  the 
abstract  type  are  to  have.  The  primary  advantage  of  this 
mode  of  specification  is  that  it  tends  to  define  the  type 
quite  generally,  in  that  only  essential  characteristics  need 
be  specified.  The  specification  is  thus  an  abstraction 
encompassing  a  relatively  large  (compared  to  an  operational 
specification)  class  of  implementations.  In  addition  to 
increasing  the  generality  of  the  specification,  the  absence 
of  superfluous  detail  tends  to  increase  the  perspicuity  of 
the  specification.  If  the  type  has  many  operations,  the 
ability  to  state  explicitly  the  relationships  among  the 
operations  may  also  have  a  beneficial  effect  on  the  clarity 
of  the  specification. 

There  are  an  enormous  number  of  formalisms  that  can  be 
used  to  construct  definitional  specifications.  The  two  most 
prominent  approaches  (in  programming)  are  the  axiomatic 
specifications  of  Hoare  [1969]  and  Scott's  lattice  theoretic 
approach  to  mathematical  semantics  [Scott  1970,1972].  The 
axiomatic  approach  is  by  far  the  more  widely  used  of  the 
two;  nevertheless,  mathematical  semantics  offers  several 
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is  considerably  less  than  that  required  to  construct  or 
understand  mathematical  semantics  definitions,  e.g.,  [Scott 
1972],  For  these  reasons,  I  have  elected  to  use  axiomatics 
as  the  basis  of  my  work  on  the  specification  of  abstract 
data  types. 

The  axiomatic  approach  I  have  adopted  owes  much  to  the 
work  of  Hoare  (which  in  turn  owes  much  to  [Floyd  1967]),  and 
is  closely  related  to  Zilles’s  "algebraic  specifications" 
[ Zilles  1975],  Its  formal  basis  stems  from  the 
heterogeneous  algebras  of  Eirkhoff  and  Lipson  [Eirkhoff 
1970],  An  algebraic  specification  of  an  abstract  type 
consists  of  two  parts;  a  syntactic  specification  and  a  set 
of  relations.  The  syntactic  specification  provides  the 
syntactic  information  that  many  programming  languages 
already  require  (see  Section  1,2):  rhe  names,  domains,  and 
ranges  of  the  operations  associated  with  the  type.  The  set 
of  relations  defines  the  meaning  of  the  operations  by 
stating  their  relationships  to  one  another,  A  formal  and 
detailed  discussion  of  this  approach  to  specification  of 
abstract  data  types  is  contained  in  Chapter  3,  A  briefer, 
and  mere  informal,  discussion  is  contained  in  the  next 
section  of  this  chapter. 
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2.3.  An  informal  look  at  algebraic  type  specifications 


Before  developing  formally  the  algebraic  specification 
technigue,  it  seems  appropriate  to  present  informally  a  few 
examples  designed  to  impart  the  flavour  of  the  approach,  and 
tc  illustrate  some  of  its  strengths  and  weaknesses.  To 
avoid  confusion,  it  should  be  pointed  out  that  though  the 
example  types  have  familiar  names,  their  specifications 
cannot  conform  to  everyone's  preconceptions  about  what  these 
names  ’’mean.*'  For  this  reason,  the  specifications  should  be 
read  as  type  definitions  rather  than  as  descriptions  of 
existing  types.  Consider  first  type  Stack  (of  Integers) 
with  the  operations  listed  in  the  previous  section.  The 
syntactic  specification  is  obvious: 


NFWSTACK: 

-> 

St  ack 

PUSH:  Stack 
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operation  applied  to  an  argument  list  containing  error  is 
error,  i.e,,  Fn  (x1 .  ,xi,error,xi-*-2,. . . ,  xn)  =  error.) 


1)  TOP  (NEWSTACK)  =  error 

2)  TOP  (PUSH(stk,int) )  =  int 

3)  POP  (NEWSTACK)  =  error 

4)  POP  (PUSH  (stk, int) )  =  stk 

This  axiomatizat ion  may  be  interpreted  as  nothing  more 
than  two  primitive  recursive  definitions.  Note,  however, 
that  while  this  interpretation  may  serve  to  increase  the 
ease  with  which  these  axioms  may  be  read,  it  is  not 
necessary.  The  axioms  may,  and  most  often  should,  be  read 
as  simple  statements  of  fact.  If  an  algebraic  specification 
(or  any  other  definitional  specification)  is  viewed  as 
defining  a  particular  computational  process,  the  level  of 
abstraction  attained  is  significantly  reduced.  The 
following  example  points  up  this  hazard.  Consider  type 
Queue  (of  Integers).  The  syntactic  specification  is  exactly 
the  domain  and  range  specification  presented  in  Section  1.2: 


NEW: 

->  Queue 

ADE: 

Queue 

X  Integer  ->  Queue 

FEONT: 

Queue 

->  Integer 

REMOVE: 

Queue 

->  Queue 

7EMPTY?: 

Queue 

->  Boolean 

A  set  of  relations  (or  axioms)  consistent  with  normal 
intuitions  about  the  meaning  of  the  above  operations  is: 
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1)  7EMFTY?  (NEW)  =  true 

2)  7EMPTY?  (ADD  (q,  i)  )  =  false 


3)  FRONT  (NEW)  =  error 

4)  FRONT (ADD (g,i) )  =  if  7EMPTY7  (q) 

then  i 

else  FRONT  (q) 


5) 

REMOVE  (NEW)  =  error 

6) 

REMOVE  (ADD (g,i)  )  =  if 

7EMPTY7 (q) 

then  NEW 

else  ADD (REMOVE (q) ,i) 


Axioms  5  and  6  are  quite  naturally  viewed  as  definin 
primitive  recursive  implementation  cf  the  operator  REMO 
If  one  accepts  this  implementation  as  the  definition 
REMOVE,  however,  then  one  is  immediately  restricted  to 
rather  small  class  of  rather  inefficient  implementations 
type  Queue. 


With  some  practice,  one  can  become  quite  adept 
reading  algebraic  axiomat izations.  Practice  also  makes 
easier  to  construct  such  specifications.  Unfortunately, 
doesn't  make  it  trivial.  It  is  not  always  immediately  cl 
how  to  attack  the  problem.  Nor,  once  one  has  constructed 
axiomat ization ,  is  it  always  easy  to  ascertain  whether 
not  the  axiomat ization  is  consistent  and  sufficient 
complete.  The  meaning  of  the  operations  is  supplied  by 
set  of  individual  statements  of  fact.  If  any  two  of  th 
are  contradictory,  the  axiomatization  is  inconsistent, 
the  combination  of  statements  is  not  sufficient  to  con 
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all  of  the  vital  information  regarding  the  meaning  of  the 
operations  of  the  type,  the  axiomati2ation  is  not 
suf f iciently-complete .  (This  term  is  defined  more  precisely 
in  Chapter  3.)  The  following  specification  of  type  Vector 
(of  Integers)  is  both  inconsistent  and  not  suf ficient ly- 
complete. 

§Hil§ctic  Specification 
EMPTY:  ->  Vector 

ASSIGN:  Vector  X  Integer  X  Integer  ->  Vector 

READ:  Vector  X  Integer  ->  Integer 

7EMPTY?:  Vector  ->  Boolean 

Axioms 

1)  7EMPTY?  (EMPTY)  =  true 

2)  7EMPTY7  (ASSIGN  (v,i ,i1) )  =  false 

3)  ASSIGN  (v,i ,i1)  =  V 

4)  READ  (ASSIGN (V, i,i1)  , i2)  = 

if  7EQDAL7 (i , i2)  /*7EQDAL7  is  an  operation  assumed 

to  be  defined  for  type  Integer*/ 

then  i1 

el^  READ(v,i2) 

To  show  that  an  axiom  set  is  inconsistent  one  need  only 
show  that  the  axioms  can  be  used  to  derive  a  contradiction. 

To  show  that  the  above  set  of  axioms  is  inconsistent,  begin 
with  the  tautology: 


7EMPTY7  (ASSIGN (EMPTY, 1,1)) 


7EMPTY7 (ASSIGN (EMPTY, 1,  1)  ) 
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Axioms  3  and  1  can  be  used  to  prove  that: 

7EMPTY? (ASSIGN (EMPTY, 1, 1) )  =  true 
Axiom  2  can  be  used  to  prove  that: 

7FMPTY?  (ASSIGN (EMPTY, 1, 1)  )  =  false 

The  transitivity  of  "="  can  now  be  used  to  derive  the 
contradiction : 

true  =  false 

That  the  specification  is  inconsistent  implies  that  the 
abstract  type  it  purports  to  specify  cannot  be  implemented. 
This  not  only  presents  anyone  attempting  to  implement  the 
abstraction  with  a  rather  severe  problem,  but  also  calls 
into  question  the  soundness  of  any  program  that  has  made  use 
of  the  type. 

The  axiom  set  is  not  sufficient ly-complete  because  it 
leaves  the  value  of  READ (EMPTY, i)  undefined.  Were  the  axiom 
set  not  inconsistent  (if,  for  example,  axiom  3  were 
deleted) ,  it  would  be  possible  to  construct  ncn-isomorphic 
models  for  the  type.  It  would  thus  be  impossible  to  predict 
the  behaviour  cf  programs  that  use  the  operations  of  the 
type.  Experience  indicates  that  completeness  is,  in  a 
practical  sense,  a  more  severe  problem  than  consistency.  If 
one  has  an  intuitive  understanding  of  the  type  being 
specified,  one  is  unlikely  to  supply  contradictory  axioms. 
It  is,  on  the  other  hand,  extremely  easy  to  overlook  one  or 
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more  cases.  Boundary  conditions,  e.g. ,  REMOVE  (NEW) ,  are 
particularly  likely  to  be  overlooked. 

In  an  attempt  to  ameliorate  these  problems,  I  have 
devised  heuristics  to  aid  the  user  in  the  initial 
presentation  of  an  axicmatic  specification  of  the  operations 
of  an  abstract  type,  and  the  theory  underlying  a  system  to 
mechanically  '’verify"  the  completeness  and  consistency  of 
that  specification.  As  the  first  step  in  defining  a  new 
type,  the  user  would  supply  the  system  with  the  syntactic 
specification  of  the  type  and  an  axiomatization  constructed 
with  the  aid  cf  the  heuristics  mentioned  above.  Given  this 
preliminary  specification,  the  system  would  begin  to  prompt 
the  user  to  supply  the  additional  information  necessary  for 
the  system  to  derive  a  complete  and  consistent  axiom  set  for 
the  operations. 

The  keys  to  the  success  of  such  a  system  are  two:  it 
must  be  able  to  recognize  a  large  class  of  complete  and 
consistent  specifications  (though  not  necessarily  all  such 
specifications) ,  and  it  must  be  able  to  direct  the  user  as 
to  what  information  would  be  sufficient  to  turn  a 
specification  that  is  not  recognizably  suf f icient ly-complete 
and  consistent  into  one  that  is.  A  detailed  discussion  of 
the  theory  underlying  a  useful  system  and  set  of  heuristics 
is  contained  in  Chapter  3, 

In  closing  this  chapter,  I  should  like  to  make  a  few 
remarks  about  the  relationship  of  my  work  on  the 
specification  of  abstract  types  to  work  that  Hoare  has  done 
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in  related  areas.  As  stated  in  Section  2,2,  my  approach  to 
the  axiomatic  specification  of  abstract  types  owes  much  to 
the  work  of  Hoare.  There  are,  however,  some  substantial 
differences  between  his  approach  and  mine.  Below  is  a 
"Hoare-like"  specification  of  an  abstract  type  Arrayl  (of 
Integers) ,  which  has  been  adapted  from  the  definition  of 
type  Array  in  [Hoare  1973].  To  conform  with  the  notation 
used  in  this  thesis,  the  statement  x[i]:=y  is  denoted 
ASSIGN  (x,  i  ,y)  ,  and  the  expression  x[i]  denoted  REA.D(x,i). 

1)  If  xi  is  an  element  of  Z  (the  set  of  all  integers) 

for  all  i  such  that  i  is  an  element  of  Z,  then 

v(x1,x2,.,.)  is  an  Arrayl. 

2)  These  are  the  only  Arrayls. 

3)  i€Z  implies  that  PEAD  ( v  (x 1 , x 2, . . . )  , i)  =  xi. 

4)  ASSIGN  (X, i ,y)  stands  for 

V  (READ  (X, 1)  , . . . , READ  (x,PBED  (i) )  ,y, READ (x,SDCC  (i) )  . . . )  . 

Eor  purposes  of  comparison,  an  algebraic  specification 
of  -^he  same  abstract  type  follows: 
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EMPTY:  ->  Arrayl 

ASSIGN:  Arrayl  X  Integer  X  Integer  ->  Arrayl 

READ:  Arrayl  X  Integer  ->  Integer 

Axioms 

READ (EMPTY,!)  =  error 

READ(ASSIGN(v,i1,i2)  , i3)  =  if  ? EQUAL?  (i 1 , i3) 

then  i2 

else  READ(v,i3) 

Aside  from  the  obvious  notational  differences  and  the 
relative  informality  (which  seems  to  lead  to  a  somewhat 
larger  set  of  "primitives")  of  Hoare*s  specifications  of 
data  types,  the  most  obvious  difference  between  his  approach 
aPxd  an  algebraic  specification  is  that  in  a  "Hoare-like" 
specification  there  is  no  syntactic  specification:  the 

names,  domains,  and  ranges  of  the  operations  are  implied  by 
the  axioms.  There  is  thus  no  external  (to  the  axiom  set) 
formal  specification  of  the  operations  to  be  defined  by  the 
axiom  set,  and  no  possibility  of  constructing  a  formal  proof 
of  the  sufficient-completeness  of  the  axiomatization  (see 
Sections  3.3  and  3.6). 


A  related 

difference 
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in  an  algebraic 

specification 

the  values 

of 

type 

Arrayl 

are  defined 

construct ively , 

the  Hoare- 

like 

speci 

f ication 

merely  asserts 

their  existence.  In  theory,  the  latter  is  a  more  powerful 
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technique  because  it  is  not  limited  to  recursively 
enumerable  sets  of  values.  It  seems  reasonable  to  assume, 
however,  that  in  practice  there  is  little  or  no  need  for 
types  with  non-constructable  carriers,  A  more  detailed 
discussion  of  the  inherent  power  of  algebraic  specifications 
is  contained  in  the  following  chapter. 
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3.  A  formal  look  at  abstract  data  types  and  their  algebraic 
specification 


Chapter  2  presented  informally  a  technique  for  the 
specification  of  abstract  data  types.  This  chapter  takes  a 
more  formal  look  at  that  technique.  This  formalization  is  a 
necessary  prelude  to  both  a  discussion  of  the  inherent  power 
of  the  specification  technique  and  the  construction  of 
conditions  sufficient  to  insure  suf ficient-completeness. 

Section  3.1  contains  a  precise  formulation  of  the  notion 
of  an  abstract  data  type  in  terms  of  heterogeneous  algebras. 
Section  3.2  relates  the  kind  of  type  specifications  used  in 
Chapter  2  to  this  formulation.  This  leads,  in  Section  3.3, 
to  a  formal  definition  of  what  it  means  to  "fully  define"  an 
abstract  type.  Section  3.U  presents  a  schema  for  axiomatic 
specifications  of  type  algebras,  and  discusses  informally 
the  relationship  of  this  schema  to  the  definition  of 
suf ficiently-complete  presented  in  the  previous  section. 
The  inherent  power  of  the  schema  presented  in  Section  3.4  is 
discussed  in  Section  3.5.  This  section  also  contains  a 
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discussicn  of  the  relationship  between  sufficent- 
ccmpleteness  and  the  totality  of  the  operations  being 
axiomatized ,  It  concludes  by  presenting  some  undecidability 
resul-'-s  pertinent  to  determining  sufficient-completeness. 
Ir  particular,  it  is  shown  that  there  does  not  exist  a 
general  procedure  for  determining  sufficient-completeness. 
Section  3.6  deals  with  determining  sufficient-completeness 
over  a  smaller  domain  of  potential  types.  It  includes  a 
presentation  of  a  set  of  conditions  that  are  sufficient  to 
guarantee  sufficient-completeness,  yet  general  enough  so 
that  there  exists  a  recognizably  su f f icient ly-complete 
axiomatization  for  any  type  all  of  whose  operations  are 
primitive  recursive.  The  final  section  deals  with 
determining  the  consistency  of  specifications. 

3.1.  7^.  definition  of  abstract  type 

An  abstract  type  is  basically  a  collection  of  values  and 
operators.  For  this  reason  it  is  quite  natural  to  view  it 
as  an  algebraic  system.  A  type  Natural  Number,  for  example, 
might  be  defined  as  the  values  0,1,2...  and  such  operations 
as 
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th€  operations  of  the  type  may  include  values  from  outside 
that  set.  For  this  reason,  the  language  of  conventional 
homogenous  algebras  is  not  well  suited  to  a  discussion  of 
abstract  data  types.  The  language  of  heterogeneous 
algebras,  on  the  other  hand,  is  quite  well  suited  to  the 
task. 

A  homogenous  algebra  A,  is  a  pair  [C,F],  where  C,  the 
carrier,  is  a  non-empty  set  of  values,  and  F  is  a  finite  set 
of  finitary  operations,  Fj.n.  Each  Fj.n  is  a  mapping: 

Fj.n:  C**n  ->  C  (For  C**n,  read  ”C  to  the  n.”) 

Eirkhoff  and  Lipson  fB^^^^hoff  1970  ]  generalized  this  to  a 
heterogeneous  algebra  [V,F],  where  V  is  a  set  of  non-empty 
sets  Vi,  called  phyla,  and  F  is  a  finite  set  of  finitary 
mappings  Fj.n; 

Fj.n:  vil  X  Vi2  X  ...  X  Vin  ->  7k,  where  ¥l<h<n[ Vihe V ] 

and  Vkev. 

This  can  be  restricted  to  a  ty^e  algebra  [V,F]  where  V 
is  a  sef  of  phyla  Vi,  1<i<m,  which  includes  a  distinguished 
phylum  called  TOI  (type  of  interest),  and  F  is  a  finite  set 
of  finitary  mappings: 

Fj.n:  Vil  X  Vi2  X  ...  X  Vin  ->  Vk  where  ¥ 1<h<n[ Vihev  ] , 

vkev,  and  at  least  one  member  of  the  set 
{Vil,  ...,vin,Vk}  is  the  distinguished  phylum  TOI. 
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Thus,  a  type  Natural  Number  may  be  defined  as  the 
algebra  [V,F]  where  V={  {true, false}  ,  {. . . -2,- 1 ,0 , 1 , 2.  •  .}  , 
{0,1,2...}  }  and  F={SDCC,  PSOE,  EQUAL,  ABS} ,  where  the 
domains  and  ranges  of  the  mappings  are  as  above.  The 
crucial  difference  between  a  general  heterogeneous  algebra 
and  a  type  algebra  is  that  the  latter  defines  one  phylum 
(TOI)  in  terms  of  the  others,  whereas  the  former  defines  a 
set  cf  phyla  by  mutual  recursion.  The  specification 
technigue  to  be  presented  in  Section  3.3.  presupposes  the 
existence  of  only  one  type:  Boolean.  (The  existence  of 
this  type,  or  at  least  of  some  two-valued  type,  is  necessary 
to  define  the  meaning  of  axioms  that  contain  conditionals.) 
In  applying  the  specification  technigue,  however,  it  is 
frequently  useful  to  presuppose  the  existence  of  other 
types.  The  specification  of  type  Symboltable  in  Chapter  5, 
for  example,  will  assume  the  existence  of  an  independently- 
defined  type  Identifier.  Theoretically,  it  would  be 
possible  to  define  several  types  at  once  via  mutual 
recursion.  It  seems,  however,  that  in  general  a  clean 
separation  of  types  leads  to  clearer  specifications. 

It  is  hardly  surprising  that  heterogeneous  algebras  are 
well  suited  to  describing  an  algebraic  system  containing 
such  common  (in  mathematics)  domains  as  natural  numbers, 
integers,  and  Booleans.  Let  us,  therefore,  consider 
another,  less  "mathematical,”  example:  type  Queue  (of 
Integers),  with  the  operations  listed  in  Chapter  1: 
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NEW: 

->  Queue 

ADC: 

Queue  X  Integer  -> 

FRONT: 

Queue  ->  Integer 

REMOVE: 

Queue  ->  Queue 

?FMPTY?: 

Queue  ->  Boolean 

F,  of  course,  is  the  set  {NEW,  ADD,  FRONT,  REMOVE,  7EMPTY?}. 

It  is  clear  that  V  must  contain  {. . . -2,-1 ,0, 1 ,2. . and 

(true, false}  and  that  m=3.  It  is  not  immediately  clear  how 
tc  represent  the  set  TOI.  This  is  not  because  of  any 

intrinsic  difference  in  the  algebraic  structure  of  queues 
and  natural  numbers,  but  is  rather  a  function  of  the  fact 
That  a  convenient  notation  for  denoting  values  of  type  Queue 
is  not  readily  available. 

This  is  a  common  problem  in  algebra,  and  is  easily 
circumvented  by  defining  the  algebra  in  terms  of  a 

generator,  rather  than  a  carrier,  set.  In  axiomatic  set 
•••heory,  for  example,  it  is  quite  normal  to  define  all  sets 
in  terms  of  the  single  generator  {  } ,  rhe  empty  set. 
Consider  Cl(G),  the  transitive  closure  cf  F  over  G,  as 
defined  by  the  construction: 

1)  XCG  implies  xecl  (G) , 

2)  Fj.nCF  and  x  1 , x2 , , . . ,xnecl (G) ,  implies  that 
Fj,n(x1,x2,,.,  ,xn)€Cl(G)  , 

3)  These  are  the  only  members  of  C1(G). 

Given  hcmogenepus  algebras  A=[C,F]  and  A *=[ Cl  (G) ,F } ,  if  A* 
is  the  least  subalgebra  of  A  that  includes  G,  and  A*=A,  then 
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G  is  a  generator  set  for  A.  The  situation  with  respect  to 
heterogeneous  algebras  is  analogous.  One  has  a  family,  Gi, 
of  generators,  and  a  family,  Ci,  of  carriers  such  that: 

1)  xeGi  implies  that  xeci 

2)  Fj.n:  Vil  X  Vi2  X...X  Vin  ->  Vk  contained  in  F,  and 
x1,x2,...,xn  contained  in  Cil  X  Ci2  X...X  Cin  implies  that 
F j.n  (x1 ,x2,. , . ,xn)  is  contained  in  Ck. 

3)  These  are  the  only  members  of  the  carriers  Ci. 

New,  returning  to  the  Queue  (of  Integers)  example,  G  may 
be  defined  as  {  {. . . -2, -1  ,  0, 1 , 2.  .  .}  ,  {true  ,  f  alse}  ,  {  }  },  or, 
more  succinctly,  {Z, Boolean,  {  }}.  There  are  two  crucial 
things  tc  note  about  this  definition.  First,  for  the  phyla 
representing  integer  and  Boolean  values,  the  generator  and 
carrier  sets  are  identical.  This  is  necessary  because, 
given  an  interpretation  that  doesn't  stray  too  far  from  what 
one  might  expect,  the  operations  of  the  algebra  will  net 
generate  new  values  of  any  phylum  ether  than  TOI.  This  will 
be  true  of  type  algebras  in  general,  and  it  is  what 
distinguishes  TOT  from  the  other  phyla.  Often,  one  will  use 
a  name  to  represent  a  phylum  other  than  TOI,  rather  than  an 
enumeration  of  its  elements.  The  second  thing  to  note  abou-*- 
V  is  that  the  generator  set  for  TOI  is  empty.  This  is  a 
conseguence  of  having  chosen  to  treat  the  constant  value  NFW 
as  a  nullary  "operation,”  rather  than  as  a  "value."  Thus 
one  of  the  operations  serves,  in  effect,  as  the  generator 
for  the  phylum.  If  the  generator  set  is  empty,  it  is 
essential  that  there  be  at  least  one  operator. 
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fn:  Vil  X  Vi2  X. .  .  X  Vin  ->  TOI, 

where  each  Vi  is  contained  in  V- {TOI} ,  for  in  a 
heterogeneous  algebra,  each  carrier  phylum  must  be  non¬ 
empty,  I  shall  follow  the  convention  of  treating  such 
nullary  (with  respect  to  the  type  of  interest)  functions  as 
operations  throughout  this  development, 

3,2.  The  semantics  of  abstract  types 


The  discussion  above  furnishes  a  method  for  the 
presentation  of  the  components  that  form  an  abstract  type. 
To  say  that  type  Queue  (of  Integers)  is  an  algebra, 

[ Cl ( {Z, Boolean, {  }  }),  {NEW, ADD, FRONT, REMOVE, ?EMPTY?}  ] 


however,  is  not  enough.  Such  a  specification  gives  no  m 
information  about  the  type  than  do  the  kind  of  domain 
range  specifications  that  such  languages  as  SIMULA  67  per 
(see  Section  1.2),  The  operations  of  the  type  still  have 
be  given  meanings. 


This  could  be  done  by  supplying  an  interpretation 
each  operation.  To  adopt  this  approach,  however,  is 
ignore  the  primary  reason  for  viewing  a  data  type  as 
algebra,  i.e.,  to  provide  a  representation-f 
specification  of  the  type  (see  Section  2.2).  For  t 
reason  I  have  chosen  to  define  the  semantics  of 
operations  of  a  type  by  supplying  a  set  of  axioms  stat 
various  properties  that  the  algebra  must  possess.  This 
of  course,  a  conventional  algebraic  approach.  The  relat 
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for  example,  is  most  often  defined  merely  by  stating 
that  it  is  reflexive,  transitive,  symmetric,  and  a=b  implies 
f(a)=f(b).  When  defining  familiar  algebraic  structures, 
e.g. ,  the  natural  numbers,  providing  an  axiomat izat ion 
presents  no  real  problem.  This  is  not,  in  general,  the  case 
for  abstract  data  types. 

The  selection  of  appropriate  axioms  depends  largely  upon 
the  type  being  defined.  It  is,  therefore,  impossible  to 
give  any  general  procedure  for  constructing  axiomatizations 
for  type  algebras.  It  is,  however,  possible  to  characterize 
the  sort  of  information  that  must  be  conveyed  by  any 
axiomatization.  That  is  to  say,  it  is  possible  to  give  a 
generalization  of  the  form  that  such  an  axiomatization 
should  take. 

A  slightly  different  notation  for  abstract  types  will 
prove  convenient  in  this  discussion.  Since  the  generator 
set  of  TOI  is  by  convention  always  empty,  it  need  not  be 
explicitly  included  in  the  specification  of  the  algebra. 
The  set  of  phyla,  V,  is  thus  replaced  by  the  set  I=V- {TOI} . 
Also,  for  reasons  which  will  become  clear  later  in  this 
discussion,  the  set  of  operations,  ?,  is  partitioned  into 
disjoint  sets  S  and  0  such  that  S  contains  exactly  those 
operations  contained  in  F  whose  range  is  TOI.  Intuitively, 
S  contains  the  operations  that  can  be  used  to  generate 
values  of  the  type  being  defined,  and  0  the  operations  that 
map  values  of  the  type  into  other  types.  The  need  for 
operations  to  generate  values  of  the  type  is  clear,  thus  S 
will  always  be  non-empty. 
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In  principle,  one  could  define  a  type  for  which  0  were 
empty.  Such  a  type,  however,  would  be  singularly 
uninteresting.  With  no  way  to  partition  the  set  TOI  (0 
empty  implies  no  predicates)  or  to  relate  members  of  the  set 
tc  members  of  other  phyla,  no  member  of  TOI  could  be 
distinguished  from  any  other  member.  That  is  to  say,  every 
value  of  the  type  would  be  equivalent  to  every  other  value 
of  the  type.  For  all  inrents  and  purposes,  there  would  be 
only  one  value  of  that  type.  The  ability  to  distinguish 
among  the  values  contained  in  TOI  thus  rests  solely  upon  the 
effect  that  these  values  have  when  they  appear  in  the 
argument  lists  of  the  operations  contained  in  0. 


A  type 

may 

now  be  characterized 

as  an  algebra. 

T=[C1  (I)  ,S+0], 

and. 

in  light  of 

the  above 

discussion,  it  is 

apparent  that 

to 

define  the 

se  mantics 

of  the  operations 

contained  in  0  is  to  define  the  semantics  of  the  type. 
Recall  *hat  all  functions  Fj.n  in  0  are  of  the  form 

Fj.n:  Vil  X  Vi2  X  ...  X  Vin  ->  Vk  where  for  1<h<n 

Vih6I+ {TOI}  and  Vkei. 

Thus,  the  semantics  of  the  type  may  be  defined  as  a  set  of 
mappi ngs 

Me:  0  X  (1+ {TOI}  )  =<'*p  ->  Vi€I 

where  p  is  the  maximum  arity  of  the  functions  in  0,  and  for 
all  Feo  and  we  (I-i- {TOI}  )  **p ,  Me  (F,  w)  =error  (a  distinguished 
error  element)  if  w  is  not  contained  in  the  domain  of  F;  and 
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Me(F,w)=y  where  yevi  for  some  Viei  if  w  is  in  the  domain  of 

F. 

An  example  may  help  to  clarify  matters.  Recall  type 
Queue  (of  Integers)  = 

[Cl( {Z, Boolean,  {  }))  ,  {NEW  , ADD , FRONT, REMOVE, 7FMPTY?} 

From  this  one  can  easily  construct  the  alge  bra 
T  =  [ Cl  ({Z, Boolean})  ,  (NEW , ADD, REMOVE}  +  {FRONT, 7EMPTY?}  ].  To 
supply  the  semantics  of  type  Queue  (of  Integers) ,  therefore, 
one  need  only  define  the  function 

Me;  {FRONT, 7EMPTY?}  X  {Z , Boolean , Queue}  ->  {Z, Boolean} 

The  problem  is  now  to  present  an  axiomatization  of  such 
a  function.  The  definition  of  Me  implies  one  axiom  that 
must  be  present  in  the  axiomatization  of  any  type: 

VFj. n ,x1 , . . . , xn{  (x1 , . . . ,xn)  not  in  the  domain  of  Fj.n  implies 
that  Me  (F j . n, X 1 , . . . , xn) =error ] 

Note  that  in  an  algebraic  specification  of  an  abstract  type 
the  domain  of  each  Fj.n  is  formally  supplied  by  the 
syntactic  specification.  Note  also  that  if  no  phylum  of  the 
type  contains  "error,"  and  this  will  normally  be  the  case, 
this  axiom  implies  that 

VF j. n ,x1 , . . . , xn[ xi=error ,  1<i<n,  implies  that 
Me  (Fj.n,x1,. . . ,xn) =error ]. 

That  is  to  say,  the  distinguished  value  "error"  has  the 
property  that  the  value  of  any  operation  applied  to  an 
argument  list  containing  "error,"  is  "error."  Since  this 


-48- 


axiom  is  a  part  of  every  type  specification,  it  will  be 
included  implicitly  in  all  subsequent  specif icaxions,  and 
will  be  referred  to  as  the  implicit  axiom. 

Given  this  implicit  axiom,  one  could,  in  the  simplest  of 
all  possible  worlds,  complete  the  axiomatization  of  a  type 
with  the  single  axiom 

VFneo , x1 , . . . , xn[ (x1 , . . . ,xn)  €  domain  of  Fn  implies  that 
Me  (Fn  ,  x1 , .  . .  ,  xn)  =w,  wher^*  w  is  a  constant  €  Vi,  1<i<m]. 

Naturally,  one  doesn’t  live  in  the  simplest  of  all  possible 
worlds.  Such  an  axiom  not  only  implies  that  all  of  the 
output  functions  of  the  type  are  identical,  but  also  that 
they  are  constant.  The  question,  then,  is  how  might  such  an 
axiomatization  be  completed? 


3.3,  The  axiomatization  of  type  algebras 

The  first  point  to  address,  is  what  it  means  to 
"complete"  an  axiomatization.  That  is  to  say,  what,  in  the 
context  of  type  algebras,  is  a  suf ficiently-complete 
axiomatization?  (I  have  introduced  the  qualifier 
"sufficiently"  to  try  to  differentiate  my  notion  of 
completeness  from  some  of  the  other,  more  common,  notions.) 
Above,  suff icient ly-complete  was  defined  informally  by 
saying  that  all  one  had  to  do  was  provide  a  semantics  for 
the  function  Me.  I  should  now  like  to  define  it  more 


rigorously 
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The  sets 

I  and  S+O  of  the  algebra  for  a 

type 

T  may  be 

used  to  define 

a  word  algebra  [Eoone 

1959]. 

The 

set  of 

words ,  L (T) , 

contained  in  this 

algebra 

are 

defined 

inductively  as 

follows : 

1)  All  elements  of  Vi€I  are  contained  in  L (T) . 

2)  If  F-j.n  is  contained  in  S+0,  and  (x1,...xn)  is 
contained  in  the  domain  of  Fj.n  and  each  xi,  1<i<n,  is 
contained  in  L(T),  then  F j.n  (x1  . ,xn)  is  contained  in 
L  (T)  . 


3)  These  are  the  only  terms  contained  in  L  (T) . 

Intuitively,  L  (T)  is  the  language  defined  by  the  abstract 
type.  It  is  eguivalent  to  the  union  of  all  the  carrier 
phyla  of  the  type,  and  defines  a  set  of  terms  that  may 
appear  in  the  body  of  any  program  in  which  the  type  has  beer- 
defined.  For  an  axiomatization  of  a  type  to  be 
suff iciently-complete,  it  must  assign  meaning  to  each  of  the 
terms  in  this  language. 

A-t  first  glance,  this  may  seem  to  be  a  formidable  task. 
Fortunately,  however,  one  need  consider  explicitly  only  a 
subset  of  1(T).  Pecall  that  the  actual  goal  is  to  define 

Ms:  0  X  (le  {TOI} )  **p  ->  Vi€I 

Thus,  one  need  consider  only  those  words  contained  in  L  (T) 
whose  outermost  operation  is  contained  in  0.  With  this  in 
mind,  the  term  suff iciently-complete  can  now  be  precisely 
d  ef ined : 
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For  any  abstract  type  T=[  Cl  (I)  , S+0  ],  and  any 
axiom  set  A,  A  is  a  suf fi ciently- complete  axiomat izat ion  of 
T  if  and  only  if  for  every  word  of  the  form  F j, n  (x1 , . . . , xn) 
contained  in  L  (T)  where  Fj.nCO,  there  exists  a  theorem 
derivable  from  A  of  the  form  Fj. n  (x1 . ,xn) =u,  where 
u€Vi€I.  A  is  consistent  if  for  each  F j. n  (x1 , . . . ,xn)  u  is 
unique . 


It  can  be  shown  (see  Section  3.5)  that  the  problem  of 
establishing  whether  or  not  a  set  of  axioms  is  suff icient ly- 
complete  is,  in  general,  undecidable.  Thus,  one  cannot  be 
provided  with  necessary  and  sufficient  guidelines  to  the 
construction  of  suff icient ly-complete  axiomatizations  of 
type  algebras.  If,  however,  one  is  willing  to  accept 
limitations  on  the  kinds  of  algebras  that  may  be  defined  and 
on  the  language  used  to  specify  the  axioms,  it  is  possible 
to  state  conditions  that  will  be  sufficient  to  ensure 
sufficient-completeness.  A  more  complete  discussion  of  this 
is  contained  in  the  next  three  sections. 


3.4.  A  schema 


for  presenting  axiomatizations 


The  language  to  be  used  for  presenting  axiomatizations 
of  abstract  types  is  essentially  that  used  in  Chapter  2.  In 
order  to  prove  things  about  the  language  itself  or  about 
axiomatizations  specified  in  the  language  it  is  necessary  to 
define  the  language  somewhat  more  formally. 
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An  axiom  set.  A,  for  specifying  an  abstract  type,  T, 
will  consist  of  the  implicit  axiom  mentioned  in  Section  3.2 
plus  a  finite  set  of  axioms,  each  of  which  is  of  the  form: 

¥x1,...,xn[lhs  =  rhs] 

¥  and  =  have  their  natural  meanings,  ¥  is  the  universal 
quantifier  "for  all,"  =  is  reflexive,  transitive, 
symmetric,  and  P  8  x=y  implies  P(x/y).  (P  (x/y)  means  P  with 
y  substituted  for  all  free  occurrences  of  x,) 

For  an  axiomat ization  of  a  type,  T,  the  number  of 
possible  relations  will  be  constrained  by  limiting  the 
possible  left  hand  sides  to  a  finite  set,  LHS.  This 
bounding  of  the  left  hand  sides  is  based  upon  the  assumption 
(discussed  in  Section  3.2,)  that  the  significance  of  the 
values  of  TOI  is  embedded  solely  in  the  effect  that  these 
values  have  when  the  appear  in  the  argument  lists  of 
operations  contained  in  0.  Thus,  any  axiom  set  in  which  all 
such  effects  were  defined  would  be  suf f iciently-comple te. 
This  train  of  thought  led  to  the  belief  that  one  could  limit 
the  set  IHS  to  those  terms  generated  by  assigning  free 
variables  to  the  arguments  of  each  s6S  and  permuting  these 
through  the  appropriate  positions  in  the  argument  list  of 
each  ceo.  Though  a  set  of  left  hand  sides  derived  via  this 
algorithm  should,  in  all  cases,  prove  sufficient,  it  may 
often  also  prove  to  be  inconvenient.  It  is  sometimes 
convenient  to  generate  left  hand  sides  in  which  operations 
contained  in  S  occur  at  the  outermost  level.  (When  will  be 
discussed  in  Section  3.6.)  The  level  of  nesting  in  rhe  left 
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hand  side,  however,  may  still  be  limited  to  two.  The  set 
LHS  is  defined  formally  as: 

LHS  =  {F j. n  (V 1 , . . . , vn)  I  Fj.neS+0,  ¥i<n[vi  is  a  free 

variable  or  vi=Fk. m  (x1 , . . . ,xm) 
and  Fk,mes+0  and  ¥l<l<m  xl  is 
a  free  variable]} 

The  set  RHS,  in  which  rhs  must  be  contained,  is  somewhat 
mere  complicated  to  define.  The  set  of  potential  right  hand 
sides,  FHSi,  for  the  ith  axiom  in  an  axiomatizat ion  of  type 
T  is  defined  inductively  as  fellows: 

1)  If  f  (11, ...,1m)  is  contained  in  L (T)  ,  and  x1,...,xm 
appear  as  free  variables  in  the  corresponding  Ihsi;  then 
f  (11 , . . . , lm/xl , . . . ,xm)  is  contained  in  EHSi. 

2)  If  b,y,zeEHSi  and  b  is  contained  in  the  phylum 
Eoclean,  then  if  b  ^en  y  else  z  is  contained  in  PHSi. 

3)  These  are  the  only  members  of  RHSi. 

The  meaning  of  the  if  then  else  construct  is,  as  one 
might  expect,  if  b  then  y  else  z  =  [ y  if  b  is  true,  z  if  b 
is  false,  and  undefined  otherwise]. 

Note  that  the  mapping  Me,  which  the  axioms  purport  to 
define,  does  not  appear  explicitly  in  the  axiomatizat ion  of 
a  type.  Nevertheless,  the  axioms  can  be  used  to  define  Me. 
Consider,  as  an  example,  a  type  Posint  (posirive  integer) : 


T  =  fCl  (  {Boolean}  ),  {ONE, SDCC,  ADD)  {TONE?}  ] 
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where  the  domains  and  ranges  of  the  operations  are: 

ONE:  ->  Posint 

SDCC:  Posint  ->  Posint 

ACD:  Posint  X  Posint  ->  Posint 

?ONE?:  Posint  ->  Boolean 

A  suitable  axiomatization  might  include  the  implicit  axiom  plus: 

1)  ¥x lePcsint , x2ePosi nt[ ADD (X 1 , x2)  =  ADD(x2,x1)] 

2)  ¥x€Posint[ ADD (ONE, x)  =  x] 

3)  ¥xiePosint,x2ePosint[ADD (SUCC (x1) ,x2)  =  SUCC (ADD  (x 1 ,x2) )  ] 

4)  ?ONE?  (ONE)  =  true 

5)  ¥x€Posint[ ?ONE? (SUCC(x) )  =  false] 

For  this  type,  0  =  {?ONE?}  and  I  =  Boolean,  thus  the 
domain  of  Me  is  [  {?ONE?}  X  Posint]  and  the  range  Boolean.  A. 
simple  induction  on  the  length  of  words  can  be  used  to  show 
that  for  all  x€Posint,  axioms  1-3  can  be  used  to  reduce  x  to 
ONE  or  SDCC* (ONE) ,  (Here,  the  *  is  the  "Kleene  star.") 
Thus,  for  any  xePosint,  ?ONE? (x)  can  be  reduced  to  either 
true  or  false.  Thus  the  mapping 

Me:  {?ONE?}  X  Posint  ->  Boolean 

is  fully  defined. 

As  a  notational  convenience,  because  all  free  variables 
are  universally  quantified  over  the  correct  type,  the 
quantifiers  that  start  each  axiom  may  be  dropped.  Hence  the 
notation  used  in  Chapter  2. 
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3,5.  The  power  of  the  schema  and  the  decidability  of 
sufficiently- complete 

Having  restricted  the  manner  in  which  type  definitions 
may  be  supplied,  it  becomes  necessary  to  address  the 
question  of  whether  or  not  the  schema  provided  is 
sufficiently  "powerful"  to  specify  any  type  that  one  might 
wish  to  define.  That  is  to  say,  does  the  class  of  algebras 
that  can  be  defined  via  the  mechanisms  provided  include  all 
of  those  algebras  that  might  prove  useful  to  a  programmer? 
The  answer  is  yes. 

Theorem  Any  algebraic  system  [ Cl  (I)  ,  S-t-0  ]  such  that 
all  the  phyla  of  I  are  recursively  enumerable  sets  and  all 
operations  contained  in  S+0  are  partial  computable  functions 
may  be  axiomatically  defined  using  only  the  primitives  (as 
defined  above)  V  (implicitly) ,  =,  and  if  then  else. 

About  the  proof ;  Following  [Minsky  1967],  a  Post  tag 
system  is  defined  by  an  initial  string  and  a  set  of 
productions  of  the  form:  gi$  ->  Shi,  where 

1)  all  the  antecedent  strings,  gi,  have  the  same  length 
(called  the  deletion  number) ,  P,  and 

2)  the  consequent  string,  hi,  depends  only  on  the  first 
letter  of  the  associated  gi, 

step  in  a  tag  system  consists  of  reading  the  first  letter 
of  the  antecedent  string,  erasing  the  antecedent  string,  and 
appending  the  consequent  string.  To  play  the  tag  system  one 
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keeps  taking  steps  until  the  resultant  string  has  less  than 
P+1  letters.  At  this  point  the  computation  halts  vith  the 
concatenation  of  all  the  intermediate  strings  as  its  value. 


In  the  following  proof  it  is  shown  that  for  any  Post  tag 
system  there  exists  an  equivalent  abstract  data  type  that 
can  be  specified  using  only  the  primitives  listed  above. 
Since  any  partial  function  may  be  defined  as  a  Post  tag 
system,  this  implies  that  the  schema  can  be  used  to  specify 
any  partial  operation,  and  thus,  by  Church's  Thesis,  any 
operation  one  can  hope  to  specify.  By  combining  these 
operations,  any  type  with  recursively  enumerable  carrier 
phyla  can  be  specified. 


of  theorem  _1 : 

1)  Below,  is  an  axiomat izat ion  of  a  generalized  Post 
tag  system  [Post  1943  ]  ?=[Cl (  (Boolean) ) , 

{BI1PTY,ZEEC,CNF,AFPEND,EFASB1  ,  STEP,  PLAY]  +  {7ZEE0?  ,  7EMFTY?}  ], 
with  an  alphabet  equal  to  {0,1}  and  a  deletion  number  of 
two.  It  has  been  specified  in  terras  of  the  primitives 
referred  to  in  the  theorem. 
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iSH s : 


EMPTY : 

ZEPO: 

ONE: 

APPEND: 

EPASE1 : 

7ZEEO?: 

7EMPTY?; 

STEP: 

PLAY: 


>  String 


->  String 
->  String 

String  X  String  ->  String 
String  ->  String 
String  ->  Eoolean 
String  ->  Eoolean 

String  X  String  X  String  ->  String 
String  X  String  X  String  ->  String 


Axioms : 


EPASE1  (EMPTY)  =  EMPTY 
EFASE1  (ZEPO)  =  EMPTY 
EFASE1  (ONE)  =  EMPTY 
EPASE1  (APPEND  (si, s2)  )  = 
if  ?FMPTY?(s1) 

then  EFASE1 (s2) 

else  APPEND (EFASE1 (si) ,s2) 

?ZEEO?  (EMPTY)  =  false 
7ZEFO?  (ZERO)  =  true 
7ZERO?(ONE)  =  false 
7ZERO  (APPEND (si ,s2)  )  = 

if  7EMPTY7(s1) 

then  7ZER07(s2) 
else  7ZER07(s1) 

7EMPTY7 (EMPTY)  =  true 
7EMPTY7  (ZERO)  =  false 
7EMPTY7(ONE)  =  false 

7EMPTY7 (APPEND  (si ,S2)  )  =  if  7EMPTY7(s1) 


then  7EMPTY?(s2) 
else  false 


STEP  (si ,s2,s3)  =  if  7EMPTY7(s1) 


then  error 


else  if  7ZEP0?  (si) 

then  APPEND (ERASE1 (ERASE1 (s 1) ), s2) 
eJie  APPEND  (ERASE1  (ERASE1  (si) ) , s3) 


PLAY (s1,s2,s3)  = 

if  7EMPTY?  (ERASE1  (EFASE1  (si)  )  ) 
then  si 

else  APPEND (si , PLAY (STEP (si ,s2,s3) , s2, s3) ) 


2)  The  PLAY  operation  in  this  algebra  can  be  thought  of 
as  a  parametric  operation.  If  one  wished  to  define  a 
particular  tag  system,  rather  than  the  universal  one  defined 
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here,  one  would  merely  have  to  replace  s2  and  sS  with 
specific  strings  generated  from  the  primitives  ZERO,  ONE, 
and  APPEND. 

3)  It  is  thus  apparent  that  the  given  schema  for 
specifying  type  algebras  is  sufficient  to  define  any  Pest 
tag  system  with  a  deletion  number  of  two  and  an  alphabet  of 
cardinality  two. 

4)  Hence,  any  partial  function  [Minsky  1967]. 

5)  Hence,  by  combining  specific  Post  systems,  any 
algebra  all  of  whose  operations  are  partial  functions. 

g . e. d  . 

Thus,  the  schema  provided  for  type  specifications  will, 
in  all  instances,  prove  to  be  sufficiently  powerful 
probably  too  powerful.  While  it  is  true  that  on  rare 
occasions  one  may  wish  to  write  a  non-terminating  program 
(e.g. ,  an  operating  system)  in  most  cases  non- termination  is 
indicative  of  an  error.  In  particular,  it  is  hard  to 
imagine  a  useful  type,  T=[C1  (I)  ,S-«-0  ],  where  0  contains  a 
potentially  non- terminating  operation.  It  therefore  seems 
useful  to  devise  restrictions  on  the  schema  for  building 
axioms,  that  will  ensure  that  only  total  functions  are 
specified  as  members  of  0.  This  is  not  to  say  that  any 
input  to  an  operation  must  be  deemed  acceptable,  e.g.,  NEW 
as  an  argument  to  FRONT  of  type  Queue,  but  merely  that  the 
operation  should  never  fail  to  terminate.  In  the  case  of  an 
unacceptable  input  it  could,  for  example,  return  the 
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dist inguished  value  "error.”  It  is,  of  course,  impossible 
to  derive  a  set  of  necessary  and  sufficient  restrictions. 
To  do  so  would  be  to  solve  the  halting  problem.  So  we 
investigate  sufficient  conditions. 

Theorem  2:  Any  conditions  that  are  sufficient  to  ensure 
sufficient-completeness  will  ensure  that  all  operations 
contained  in  0  are  total. 

it heorem  2 : 

1)  If  (x1,...,xn)  is  not  contained  in  the  domain  of  Pn, 
then,  by  the  implicit  axiom,  Fn  (x 1 , . . . , xn) =error .  Thus 
yPnes  +  O, X 1 , . . . , xn  [ Fn  (x 1 , . . . , xn)  not  contained  in  L  (T) 
implies  that  Fn  (x1 , . . . , xn)  converges]. 

2)  If  Fn  (x1 , . . . , xn) €L  (T)  and  Fn0O,  then,  by  the 
definition  of  suff iciently-complete ,  there  exists  a 
u€  ( (V iei)  +  {error} )  such  that  F  (x1 ,. . . ,xn) =u.  Thus  for  all 
Fn  (x1 , . . . , xn) 01  (T) ,  Fn0O  implies  that  Fn  (x 1 , . . . , xn)  has  a 
definite  value . 

g.e. d. 

It  is  important  that  suff iciently-complete  implies  that 
all  operations  contained  in  0  are  total.  From  the  user's 
point  of  view,  it  means  that  if  his  axiomat izat ion  is 
suff iciently-complete,  he  not  only  learns  something  about 
the  axiomatization,  but  he  also  learns  (or  is  reassured 
about)  something  about  the  operations  that  have  been 
axiomatized.  Mors  importantly,  theorem  2  also  serves  to 
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highlight  the  difficulty  involved  in  checking  the 
sufficient-completeness  of  an  axiomatization. 

Ideally,  one  would  like  to  be  able  to  construct  a  total 
f unct ion 

R:  axiomatizat ions  X  syntactic  specif icarions  ->  Boolean 

such  that  P(A,sE)=true  if  A  is  a  sufficient ly-complete 
axiomatization  of  ss,  and  false  otherwise.  However,  since, 
as  implied  above,  such  a  function  could  be  used  to  solve  the 
halting  problem,  it  is  clear  that  no  such  function  exists. 
Thus,  one  is  led  to  consider  a  slightly  less  informative 
function,  and  a  somewhat  different  notion  of  completeness. 

Definition ;  Given  a  total  function  R  such  that 
R(A,ss)=true  implies  that  A  is  a  suf f iciently-complete 
axiomatization  of  ss,  A  is  recognizably  sufficient ly- 
with  respect  to  R  (r.s.c.(R)),  if  and  only  if 
R  (A,  ss)  =  true . 

Unfortunately,  this  problem  cannot  be  solved  completely 
satisfactorily  either. 

Theorem  3:  There  do<=s  not  exist  a  function  R  for 

determining  suf f icient-completeness  such  that  for  all  types 
T=[C1  (I)  ,  S+0  ]  where  Feo  implies  that  F  is  total,  there  exist: 
r.s.c.(P)  axiomatizations. 
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ill®  proof :  It  is  shovn  that  if  the  theorem  were 
not  true,  the  set  of  all  total  functions  would  be 
recursively  enumerable.  Since  this  is  known  to  not  be  the 
case,  the  theorem  must  be  true. 

ill®2I®i!l  1  * 

1)  Assume  that  theorem  3  is  not  true.  I.e.,  that  there 
exists  a  function  B1  such  that  for  all  T=[C1(I)  ,S  +  0],  if  all 
F60  are  total,  then  there  exists  a  suf f iciently-complete 
axiomatizat ion  ,  A,  of  I  such  that  R1  (A, ss  (T) ) =true ,  and 
further  for  all  axicmat izations  A',  A'  not  suf f icienr ly- 
ccmplete  implies  than  P 1  (A ' , ss  (T) ) =f alse . 

2)  Theorem  2  has  an  obvious  corollary:  that  for  any 
function  P,  any  type  T=f Cl  (I)  ,S+0],  and  any  axiom  set  A;  if 
A  is  a  r.s.c.(P)  axiomat ization  of  the  syntactic 
specification  of  T  (ss(T)),  then  all  operations  contained  in 
0  are  total. 

3)  The  set  of  all  function  names  is  known  to  be 
recursively  enumerable  (r.e.). 

4)  Therefore,  because  the  r.e.  sets  are  closed  under 
powerset,  the  set  of  all  sets  of  function  names  is  r.e. 

5)  Thus  the  set  of  all  syntactic  specifications  is  r.e. 

6)  For  any  syntactic  specification,  the  set  of 
axiomatizations  (according  to  the  schema  I  have  presented) 


IS  r.e 
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7)  From  5  and  6  the  set  of  all  pairs  <A,ss(T))  is  r.e. 

8)  From  7  and  E= {T=[ Cl  (I)  , S+0  ]  |  there  exists  an 

r,s.c.(B1)  axiomatizat ion  of  T}  is  r.e. 


9)  Thus 
T€E  and  oCC} 


the  set  B0=  (o 
is  r.e. 


there  exists  T=[  Cl  (I)  ,  S+0  ]  and 


10)  Thus  the  set  FO=  {F  |  F€BO}  is  r.e. 


11)  From  2,  F6F0  implies  that  F  is  total. 

12)  From  1,  all  total  functions  are  contained  in  FO. 

13)  11  and  12  imply  that  FO  is  the  set  of  all  total 
functions,  10  that  this  set  is  r.e. 

1 U)  But  this  is  known  not  to  be  the  case  [ Brain erd 
1974],  Hence  the  assumption  of  1  must  be  false. 


g .  e. d . 

The  ramifications  of  this  are  net  so  unfortunate  as  they 
may  at  first  appear  to  be.  In  programming,  the  occasions 
when  one  has  need  of  a  non- primitive  recursive  function  seem 
to  be  very  rare  indeed.  It  thus  seems  that  if  one  were  to 
construct  a  decision  procedure,  B2,  such  that  for  all  types 
where  all  operations  are  primitive  recursive  there  exist 
r.s.c.(P,2)  axiomatizations,  one  would  have  a  procedure  that 
would  be  useful  for  a  wide  range  of  applications.  A  set  of 
restrictions  on  the  schema  for  supplying  axiomatizations  of 
types  around  which  such  a  decision  procedure  can  be  built  is 
presented  in  the  next  section. 
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3.6.  Sufficient  conditions  for  establishing  sufficient- 
ccinpleteness 

Chapter  2  contended  that  one  of  the  main  difficulties  in 
supplying  axiomatic  specifications  of  abstract  data  types  is 
knowing  when  one  has  "fully  specified"  the  type.  It  also 
suggested  that  this  problem  could  be  ameliorated  by  ohe  use 
of  a  system  that  could  check  the  completeness  of  an 
axiomatization  and  suggest  ways  of  completing  an  incomplete 
specification.  In  Section  3.3  of  this  chapter,  however,  it 
was  demonstrated  that  in  the  general  case  the  sufficient- 
completeness  problem  is  unsolvable,  i.e.,  there  cannot  exist 
a  decision  procedure  for  recognizing  sufficient¬ 
completeness,  Section  3.5  proved  an  even  stronger  result: 
that  there  does  not  exist  a  semi- decision  procedure,  P,  such 
that  for  all  type  algebras  there  exists  an  axicma t izat ion 
that  is  recognizably  suf f iciently-complete  with  respect  to 
P.  Thus,  the  scope  of  any  system  such  as  that  suggested  in 
Chapter  2  must  necessarily  be  somewhat  limited. 

In  this  section,  I  shall  present  a  set  of  conditions 
that  are  sufficient  to  guarantee  that  an  axiom  set  is 
sufficient ly-complete.  I  shall  also  prove  that  for  any  type 
[Cl(I),S+0]  if  all  members  of  S+0  are  primitive  recursive, 
there  exists  an  axicma tization  of  that  type  that  fulfills 
these  conditions.  These  conditions  can  thus  serve  as  the 
basis  of  a  semi- decision  procedure  rhat  can  be  used  to  show 
the  sufficient-completeness  of  a  large  number  of 
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axiomatizations.  A  SNOECL  implementation  of  such  a 
procedure  has  been  produced. 

Conyentipn :  It  will  be  assumed  that  for  all  operations 
contained  in  S+0  all  arguments  contained  in  TOI  precede  all 
arguments  contained  in  other  phyla  in  the  operation's  domain 
specification.  This  implies  that  each  operation  is  of  the 
form  f(y*)  or  f(x,y’*')  (the  y*  indicates  a  list,  possibly 
empty,  of  arguments)  where  x  is  contained  in  TOI. 

Definition :  A  -^erm  is  atomic  with  respect  to  the  type 
of  interest  if  it  contains  no  operations  contained  in  S+0. 
Note  that  such  a  term  must  be  contained  in  Vi€I. 

is  one  nhat  contains  no  free 

variables . 

2“fillili22i*  Consider  an  axi cmatiza tion.  A,  of  a  type 
T=[ Cl  (I)  , S+0  ].  A  term  of  the  form  o(x,y*)  where  oCO  and  x 
and  are  free,  is  safe  if  for  all  assignments  to  x  and  y*, 
there  exists  a  theorem  derivable  from  A  of  the  form 
o(x,y*)=z,  where  z  is  atomic. 

axiomat  ization  A  is  a  safe 
axiomatizat ion  of  a  type  T=[ Cl  (I)  , S+O  ]  if  ?oeo,  o(x,y*)  is 
safe. 


It  should  be  clear  that  the  notion  of  safe  is  closely 
related  to  that  of  suf f ic ient ly-complete.  Because  z  atomic 
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implies  that  z  is  contained  in  Viei,  o(x,y*)  safe  for  al 
and  y*  implies  that  the  operation  o  is  fully  defined,  i. 
if  for  all  oeo,  o(x,y*)  is  safe,  then  the  axiomatizat 
must  be  suf f icient ly-complete .  The  safety  problem,  like 
sufficient-completeness  problem,  is  unsolvable  in 

general  case.  It  is,  however,  possible  to  deve 

conditions  that  are  sufficient  to  guarantee  the  safety 
all  terms  of  the  form  o(x,y*). 


Consider  a  simplified  schema  for  the  axioma tization 
abstract  data  types:  one  in  which  the  if  then  e 

conditional  has  been  eliminated.  That  the  loss 
ccmoutational  power  attributable  to  this  simplif icex ion 
not  overly  severe  will  be  demonstrated  later  in  this  chap 
(theorem  7) .  Experience  has  indicated,  however,  that 
conditional  adds  considerable  expressive  power.  It  wi 
therefore,  be  reintroduced  later  in  this  development.  Gi 
these  restrictions,  we  derive  some  lemmas  about  our  ax 
systems  in  general. 

•  For  any  computable  measuring  function 
M:  free  terms  ->  Natural  numbers,  an  axiom  lhs=rhs 
Lb  1?  (in(M))  if  and  only  if  M  (Ihs)  >M  (rhs)  . 


Now,  let  us  consider  a  particular  measuring  funct 
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|c(s(j))|  where  oeo ,  s€S,  and  j€Viei,  for  example,  equals 
one. 


Lemma  h:  A  is  a  safe  axicmat ization  of  T=[ Cl  (I) , S+0 ]  if 
Vceo  and  ¥£€3  there  exists  a  m(|  |)  axiom  of  the  form 

c  (s(x,y*)  ,w*)  =z. 

Ihi.  2I£2£‘  theorem  is  shown  to  be  true  by 

induction  on  | o (s (x, y*) , w*)  | .  Since  (by  the  definition  of 
I  I)  |o  (£  (x^y’^')  1>0,  |o  (s  (x,y’<')  ,w*)  I  =1  is  used  as  the 

basis  cf  the  induction. 

£l2of  of  lemma  A: 

1)  From  the  statement  of  the  lemma  it  is  clear  that  for 
any  ground  term  cf  the  form  o  (s (x ,y *) , w*)  it  is  possible  to 
derive  a  theorem  of  the  form  o (s ( x , y*) , w*) =z  where 
|o  (s(x,y*)  ,w’«')  |>|z|. 

2)  If  I  o  (s  (x ,  y*)  ,  w*)  I  =1 ,  then  lz|=0.  z  must,  therefore, 
be  atomic.  This  forms  the  basis  of  the  induction, 

3)  Assume  that  for  any  ground  term  o  (s  (x,y’i')  , w’#')  such 
that  I o (s  (X, y*) , w*)  I <n  it  is  possible  tc  derive  a  theorem  of 
the  form  c (s (x ,y*) , w*) =z  where  z  is  atomic. 

4)  Consider  any  ground  term  o  (s (x , y *) , w*)  with  depth  of 
nesting  n+1.  Step  1  asserts  that  it  is  possible  to  derive  a 
theorem  of  the  form  o (s (x , y *) , w*) =z  where  |z|<n. 
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5)  Since  this  2  must  be  contained  in  I,  it  must  be 

either  atomic  or  of  the  form  o1  (si  (x1 , y 1*) , w1 *)  .  In  the 
latter  case,  it  must,  by  the  induction  hypothesis  3,  be 

possible  to  derive  a  theorem  of  the  foim  o  1  (si  (x , y=«')  , w*)  =2l 
where  2I  is  atomic. 

q  .  e.  d  . 

While  the  conditions  outlined  in  lemma  A  are  sufficient 
to  ensure  the  safety  of  an  axioma tization ,  they  are  far  more 
restrictive  than  is  necessary  or  desirable.  In  particular, 
it  is  not  necessary  to  insist  that  there  be  a  monotone  axiom 

for  each  term  of  the  form  o  (s  (x  ,y=^)  ,  w*)  ,  One  might,  for 

example,  wish  to  define  addition  over  the  natural  numbers 
using  the  axioms: 

1)  ADC  (ZERO, X)  =  ADD(x,ZERO) 

2)  ADD  (SUCC  (X)  ,y)  =  ADD  (y  ,  SDCC  (x)  ) 

3)  ADD(x,ZEPC)  =  X 

H)  ADD  (X,  SUCC  (y) )  =  ADD  (S UCC  ( x)  , y ) 

(The  ability  to  "abbreviate”  the  first  two  axioms  by  the 
single  axiom  ADD (x, y) =AED (y, x)  makes  this  kind  of 
a xiom atization  quite  convenient  in  some  situations.)  Lemma  P 
allows  for  non-monotone  axioms. 

Lemma  P:  A  is  a  safe  axiomat  ization  of  T=[C1(I)  ,S+0]  if 
Vc€0  and  Vs€S  there  exists  an  axiom  of  the  form 
o  (s (x,y*) ,w*)  =  z,  where  either 


I)  the  axiom  is  m(|  |) 
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II)  there  exist  axioms  z=z1 ,  z1=z2,...,  zn=zn+1  and 

z=zn-t- 1  is  m  ( I  | )  , 

of  IflM  E: 

Fellows  immediately  from  lemma  A. 

Fecall  that  the  above  discussion  deals  with  axioms  in 
which  the  right  hand  side  contains  no  conditionals.  This 
deficiency  is  remedied  by  lemma  C. 

ref inition :  An  axiom  that  meets  either  condition  I  or 
condition  II  as  stated  in  lemma  B  is  said  to  be  Bsafe. 

Lemma  C:  A  is  a  safe  axiomat  izat  ion  of  T=[  Cl  (I)  ,  S•^0  ]  if 
yoeo  and  yses  there  exists  an  axiom  of  the  form 
o  (s  (x  , y*)  ,  w’*')  =z  where  either 

I)  z  contains  no  conditionals  and  the  axiom  is  Bsafe 

II)  z  is  of  the  form  if  b  then  z1  else  z2  where  b  is 
Boolean,  o  (s  (x  ,y *)  , w*)  =z1  and  o  (s  (x, y’^')  ,  w*)  =z2  are  Bsafe, 
and  I b I < I o  (s  (X, y*) , w*)  I  or  the  range  of  o  is  Boolean  and 
o  (s  (x  ,  y*)  ,  w*)  =b  is  Bsafe, 

1)  The  conditions  placed  on  b  guarantee  that  for  any 
ground  instance  of  b  it  is  possible  to  derive  a  theorem  of 
the  form  b=true  or  a  theorem  of  the  form  b=false. 
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2)  Thus,  for  any  ground  instance  of  o  (s  (x , y*) , w*)  it 
will  he  possible  to  derive  either  o (s (x, y*) , w*) =z1  or 
o  (s  (X  ,y*)  f  w*)  =z2. 

3)  The  last  stipulation  in  II  above  and  lemina  B 
guarantee  that  these  will  be  reducible  to  atoms. 

q . e. d  . 

Note  that  lemma  C  still  does  not  provide  for  nested 
conditionals.  Theorem  4,  which  concludes  our  development  of 
sufficient  conditions  to  ensure  safety,  remedies  this. 

axiom  that  meets  either  condition  I  or 
condition  II  of  lemma  C  is  said  to  be  Csafe. 

axiom  that  meets  either  condition  I  or 
condition  II  of  theorem  4  (below)  is  said  to  be  4safe. 

Theorem  :  .t  is  a  safe  axiomatization  of  T=[  Cl  (I)  ,  S+0  ] 
if  Vo€0  and  ¥ses  there  exists  an  axiom  of  the  form 
o  (s  (x , y *)  ,  w*)  =z  where  either 

I)  the  axiom  is  Csafe,  or 

II)  z  is  of  the  form  if  b  then  z1  else  z2  where  b  is 
Boolean,  o  (s  (x,y*) ,w*) =z1  and  o (s (x, y*) , w*) =z2  are  4safe, 
and  |b|<|o  (s (x,y*) ,w*)  |  or  the  range  of  o  is  Boolean  and 
o  (s  (x  , y *)  ,  w*)  =b  is  4saf€. 
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of  Theorem  4: 

1)  Consider  an  axiom  o  (s  (x  ,y ,  w*)  =z.  If  there  is  no 
nesting  of  conditionals  in  z,  then,  by  lemma  C,  the  theorem 
holds.  This  forms  the  basis  of  an  induction. 


2)  Assume  that  the  theorem  holds  if  the  level  of  nesting 
of  conditionals  in  z  is  <n. 


3)  Consider  the  case  where 
depth  of  n+i  in  z. 

4)  Consider  the  outermost 
the  form  if  b  then  z1  else  z2. 
guarantee  that  for  any  ground 
to  derive  a  theorem  of  the  form 

6)  Thus,  for  any  ground 
will  be  possible  to  derive 
o  (s  (x  ,\i*)  =z2. 


conditionals  are  nested  to  a 

conditional.  It  must  be  of 
The  conditions  placed  on  b 
instance  of  b  it  is  possible 
b=true  or  b=false. 

instance  of  o  (s  (x  ,y *)  ,  w*)  it 
either  o  (s  (x, y*)  , w*) =z1  or 


7)  The  depth  to  which  conditionals  are  nested  in  z1  or 
z2  must  be  <n .  Thus,  by  the  induction  hypothesis,  the 
theorem  holds. 

q. e. d. 

As  suggested  earlier,  this  theorem  leads  directly  to  a 
set  of  conditions,  P2,  that  are  sufficient  to  ensure 
sufficient -completeness.  To  wit,  if  an  axiomat izat ion  of  an 
abstract  data  type  meets  the  conditions  outlined  in  theorem 
4,  then  the  axiomatiza tion  is  sufficient ly-complete.  At 
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first  glance,  this  may  not  seem  to  be  a  significant 
improvement  over  earlier  formulations  of  sufficient- 
completeness.  Note,  however,  that  the  number  of  terms  that 
must  be  checked  is  a  finite  number  equal  to  the  product  of 
the  cardinalities  of  the  sets  0  and  S.  Call  this  product  P. 
Note  also  that  any  axiomatization.  A,  contains  a  finite 
number  of  axioms.  Call  this  number  N.  Thus,  there  is  a 
finite  bound  on  the  time  required  to  determine  whether  or 
not  a  set  of  axioms  is  an  r.s.c. (B2)  axiomatization  of  any 
given  type.  The  actual  bound  is  order  PN.  Since,  given  the 
above  scheme,  the  number  of  axioms  required  for  a 
recognizably  suff iciently-ccmplete  axiomatization  is  equal 
to  the  number  of  terms  to  be  checked,  this  can  be  rewritten 
P2. 


Unfortunately,  P^,  though  finite,  can  be  large.  The 
situation  is  particularly  bad  when  one  allows  more  than  one 
partially  bound  argument  of  TOI  in  the  left  hand  sides  of 
axioms,  and  permutes  the  members  of  S  through  the 
appropriate  positions  in  the  argument  list  of  each  operation 
contained  in  0.  Consider,  for  example,  type  Natural  Number 
=  [Cl  ({true, false})  ,  (ZEPO ,SUCC, PPED , ADD , MULTIPLY} ♦ 
{?ZEPO?,?EQUAL?}  ].  The  terms  that  would  have  to  be  checked 
number  30.  Ey  providing  axioms  that  relate  values  in  TOI  to 
one  another,  e.g. ,  ADD  (SUCC  (x) , ZEBO)  =  SUCC(x),  however,  the 
number  of  terms  to  be  considered  can  be  substantially 
reduced.  Hence  the  notion  of  convertibility.  Informally, 
if  the  values  "generated"  by  an  operation  F,  can  always  be 
expressed  in  terms  of  other  operations,  then  F  is  said  to  be 
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ccnvertible.  In  type  Natural  Number,  for  example,  all  terms 
of  the  form  PEED(x)  are  convertible  to  either  ZERO,  error, 
or  SDCC(y);  where  y  does  not  contain  PEED.  Convertible 
operations  are  essentially  ’’functional  extensions”  whose 
meaning  could  be  given  (outside  the  type  definition)  purely 
in  terms  of  the  other  operations  on  the  type.  They  may 
increase  the  expressive  power  of  the  type,  but  not  its 
inherent  computational  power.  More  formally: 

Given  an  axiom  set  A  and  a  type 
[ Cl  (I) ,S  +  0+ {f}  ]  where  f:  TOI  X  Vi  1  X...X  Vin  ->  TCI  is  not 
contained  in  S,  if  for  all  ground  terms  of  the  form  f(u,v*) 
there  exists  a  theorem  derivable  from  A  of  the  form 
f(u,v*)=z  where  z  contains  no  instances  of  f,  then  f  is  said 
to  be  convertible  to  S. 

Now,  consider  a  type  T=[ Cl  (I) , S+0  ]  with  a  sufficient ly- 
ccmplete  axiomat ization  A.  Lemma  D  presents  conditions  that 
are  sufficient  to  ensure  that  given  an  axicmatiza tier  AtA' 
of  type  T '  =[ Cl  (I)  ,  S+0+ {f}  ],  f  is  convertible  to  S. 

!2§Iiliition :  For  any  term  x  and  any  operation  f,  Mf  (x) 
is  equal  to  the  number  of  instances  of  f  that  appear  in  x. 

Lemma  D:  Consider  types  T=[ Cl  (I)  , s  +  0 ]  with 

C 

axiomatizaticn  A,  and  T ' =[ Cl  (I)%  S+0+ [f]  ]  with  axiomatizat ion 
A+A*.  f  is  convertible  to  S  if  for  all  terms  of  the  form 
f  (s  (x*)  ,  y’*')  where  s0S  and  all  members  of  x’*'  and  y*  are  free 
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variables,  there  exists  in  A*  an  axiom  of  the  form 
f  (s (X*) , y*) =z  where  either 

I)  Mf (z)  =0 ,  or 

II)  s  is  not  a  constant  (i.e.,  it  is  not  nullary  with 
respect  to  TOI) ,  and  for  every  subterm,  w,  of  z  (includinq  z 
itself),  if  w  is  of  the  form  f(u,v*),  then  u  is  a  free 
variable  contained  in  x*  and  all  members  of  v’*'  are  free 
variables  contained  in  y*. 


^bout  the  proof; 

It  is  shown  by  ind 

uct ion 

that 

for  any 

ground  term  of  the 

form  f  (s  (a*)  ,  b*)  , 

where 

s€S , 

it  is 

possible  to  derive 

a  theorem  of  the 

form  f 

(s(a^) 

rb*)  =Z, 

where  Mf  (f  (s  (a*) , b*) ) >Mf  (z) .  A  sublemma,  D,1,  is  then 
invoked  to  show  that  this  is  a  sufficient  condition  to 
guarantee  the  convertibility  of  f. 

Sublemma  If  for  each  ground  term  of  the  form 

f  (s (a*) , b*)  where  ses  it  is  possible  to  derive  a  theorem  of 
the  form  f  (s  (a*) ,b*) =z,  where  Mf  (f  (s  (a*) , b*) >Mf  (z)  ,  then  f 
is  convertible  to  S. 


About 

proof :  This 

proof 

by  induction  is  gu 

ite 

similar  to 

the  proof  of  lemma 

A. 

The  major  difference 

is 

that  the 

measuring  function 

I 

I 

has  been  replaced  by 

Mf . 

The  indue 

tion  is  thus 

on 

Mf  (f(s(a*),b*)),  w 

ith 

Mf  (f  (s  (a*) , b*) =1  serving  as  the  basis. 
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£1221  2l  £il  • 

1)  From  the  statement  of  the  lemma,  for  any  ground  term 
of  the  form  f  (s  (a*)  , b'*')  it  is  possible  to  derive  a  theorem 
of  the  form  f  ( s  (a *)  , b*)  =z  where  Mf  (f  (s  (a*)  ,  b*)  )  >Mf  (z)  . 

2)  If  Mf  (f  (s  (a*) , b*) ) = 1  then  Mf  (z) =0,  i.e.,  z  contains 
no  instances  of  f.  This  forms  the  basis  of  the  induction. 

3)  Assume  that  for  any  ground  term  f  (s  (a*)  ,b’<')  such  that 

Mf  (f  (s  (a*)  , b’*')  )  <n ,  it  is  possible  to  derive  a  theorem  of  the 
form  f  (s  (a*)  ,  b*)  =z  where  Mf(z)=0,  I.e,,  assume  that 

f(s(a*),b*)  is  convertible. 

U)  Consider  any  ground  term  f  (s  (a*)  ,b=*‘)  with 
M f  (f  (s  (a’*') ,  b*)  )  =n+ 1 .  From  step  1  it  is  clear  that  it  is 
possible  to  derive  a  theorem  of  the  form  f  ( s ( a*)  , b*) =z  where 
Mf  (z)  <n. 

5)  Py  the  induction  hypothesis,  3,  this  term  must  be 
convertible. 

q . e. d  . 

£l22l  2l  Ifmma  D: 

1)  Consider  any  ground  term  f(s(a*),b*)  such  that 
I s  (a*)  1=0.  s  must  be  a  constant,  thus  case  II  of  lemma  D  is 
net  applicable.  Hence,  there  must  exist  an  applicable  axiem 
of  the  form  f  (s  (x*)  ,  y’«')  =z  where  Mf(z)=0,  Thus,  we  may 
directly  derive  a  theorem  of  the  form  f  (s  (a*)  ,b=<‘)  =z  1  where 
Mf  (f  (s  (a*)  ,b*)  >Mf  (z1)  . 


-74- 


2)  Assume  that  if  (s  (a*)  |<n  then  for  any  ground  term  of 
the  form  f(s(a*),b*)  it  is  possible  to  derive  a  theorem  of 
the  form  f  (s  (a*)  ,  b*)  =z  1  where  Mf  (f  (s  (a*)  ,  b*)  )  >Mf  (z1)  . 

3)  Consider  any  ground  term  f(s(a*),b*)  such  that 
|s(a*) |=n+1.  The  lemma  asserts  that  there  must  be  an 
applicable  axiom  f  (s (x*) , y*) =z  such  that  either 

a)  f1f(z)=0.  In  this  case  it  is  possible  to 
directly  derive  a  theorem  of  the  form  f  (s  (a*) , b*) =z 1  where 
Hf  (f  (s  {Si*)  ,b*)  >Mf  (z)  . 

b)  It  is  possible  to  directly  derive  a  theorem  of 

the  form  f  (s  (a *) , b*) =z 1  where  for  all  subterms  of  z1  of  the 
form  f(u,v*) ,  u  must  be  a  member  of  a*.  |u|  must, 

therefore,  be  less  than  |s(a*)|,  i.e.,  jul<n.  Therefore,  by 
the  assumption  of  step  3,  it  is  possible  to  derive  a  theorem 
of  the  form  f(u,v*)=z1  where  Mf  (f  (u,v*)  )  >Mf  (z1)  . 

4)  By  induction,  it  is  therefore  possible  to  derive,  for 
any  ground  term  of  the  form  f(s(a*),b*),  a  theorem  of  the 
form  f  (s  ( a*)  ,  b^)  =z  where  Kf  (f  (s  (a ’*')  ,b*)  >Mf  (z)  . 

5)  Therefore,  by  sublerama  D.1,  f  is  convertible  to  S. 

g  •  e  •  d  # 

Like  lemma  A,  lemma  D  makes  no  provision  for 
conditionals.  This  is  rectified  in  theorem  5. 

Pt axiom  that  meets  either  condition  I  or 
condition  II  of  lemma  D  is  said  to  be  Dok. 
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Theorem  5:  All  free  terms  of  the  form  f(x,y*)  are 

convertible  to  S  if  ¥s€S  there  exists  an  axiom  of  th®  form 
■p  (s  (X*)  ,  y*)  =z  where  either 

I)  z  contains  no  conditionals  and  the  axiom  is  Dok. 

II)  z  is  of  the  form  if  b  then  z1  else  z2  where  b  is 
Boolean  and  atomic,  or  Boolean  and  Usafe,  and  f  (s  (x*)  ,y*) =zl 
and  f  (s  (X*)  ,y*)  =z2  are  Dok. 

of  5: 

1)  The  conditions  placed  on  b  guarantee  that  for  any 
ground  instance  of  f  (s  (x=«‘)  ,  y^^')  it  is  possible  to  derive  a 
theorem  of  the  form  b=true  or  one  of  the  form  b=false. 

2)  Thus,  for  any  ground  instance  of  f  (s  (x=<‘)  ,  y*)  it  will 
be  possible  to  derive  a  Dok  theorem  of  the  form 
f  (s  (X*)  ,y*)  =z, 

3)  Lemma  D  asserts  that  this  is  a  sufficient  ccnditicn 
to  guarantee  that  all  terms  of  the  form  f  (s  (x’*‘)  ,  y*)  are 
convertible. 

q . e. d. 

The  concept  cf  convertibility  combined  with  that  of 
safety  leads  to  a  second  set  of  conditions,  E3,  that  are 
sufficient  to  guarantee  sufficient-completeness. 

Informally,  if  «=very  term  of  the  form  o(x,y*),  where  oeo,  is 
either  safe  or  convertible  tc  something  that  is  safe,  then 
the  axiomatization  is  suf f icient ly-complete. 


More  formally: 
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Theorem  6:  axiom  set.  A,  for  a  type,  T=[  Cl  (I)  ,  S+O  ], 
is  sufficient ly-complete  if  there  exists  a  partitioning  of  S 
into  disjoint  sets  NC  and  C  such  that  all  constants  are 
contained  in  C  and 

1)  For  all  cec  and  all  o€0,  the  term  o(c(x*),y*),  where 
the  members  of  x*  and  y*  are  free,  is  safe,  and 

2)  There  exists  an  ordering,  nc1, nc2,. , . ,ncm,  of  the 
functions  in  NC,  such  that  ncl  is  convertible  to  C,  nc2  is 
convertible  to  C+  {ncl} ,  etc, 

About  the  £roof:  It  is  first  shown  (steps  1-3)  that  it 
is  sufficient  to  prove  that  for  all  ground  terms  of  the  form 
o  (c  (x=<‘)  ,  y  *)  ,  oeo  and  c6C,  there  exists  a  theorem  of  the  form 
o  (c  (X*)  ,  y=*‘)  =2,  where  z  is  atomic  or  safe.  That  this  is  true 
follows  immediately  from  the  definition  of  safe  and  the 
initial  conditions  specified  in  the  theorem, 

£^2°!  2f  theorem  6 : 

1)  Pecall  that  an  axiom  set.  A,  is  suf f icier.t ly-complete 


if  and 

only 

if  for 

all 

w  =  Fj,n(x1,, 

, ,  ,  xn)  CL  (T)  where 

F j,n€0. 

there 

exists 

a  theorem  derivable  from  A  such  that 

the  the 

orem  is 

of  the 

form  w 

=u  where  u  is 

contained  in  Vi€I, 

Recall 

also 

that  ueviei 

implies  that 

u  is  atomic  with 

respect 

to  TOI 

• 

2)  Fj,neo  implies  that  at  least  one  of  x1,,,,,xr.  is 
contained  in  TOI,  thus  (by  our  convention)  xlCTOI,  xlCTOI 
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implies  that  x1  is  either  a  constant  or  of  the  form  s(u, v’*'), 
s€S. 

3)  Because  all  terms  of  the  form  nc(x,y*)  where  nc€NC, 
are  convertible,  we  need  only  consider  those  terms  w  where 
x1  is  a  constant  or  of  the  form  c(u,v*)  and  cec, 

4)  Thus  we  need  only  show  that  for  any  assignment  to  the 
free  variables  of  all  terms  of  the  form  o(c(x*),y*)  where 
oeo  and  cec,  there  exists  a  theorem  of  the  form 
o  {c (x*) ,Y*)  ,  where  2  is  atomic  with  respect  tc  TOI. 

5)  That  is  to  say  all  free  terms  of  the  form  o  (c  (x*)  ,  y’*') 
must  be  safe.  This  is  guaranteed  by  the  first  condition  of 
the  theorem. 

q .  e.  d . 
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sufficient-completeness  must  not  only  be  guaranteed  against 
returning  spurious  values,  but  also  must  be  capable  of 
recognizing  a  large  class  of  sufficient ly-complete 
axiomatizaticns.  Almost  all  of  the  algebraic  specifications 
of  abstract  types  that  I  have  constructed  were  either 
"naturally”  r.s.c.(P3)  or  not  suff iciently-complete .  (In 
the  latter  cases  the  application  of  R3  often  served  to 
indicate  how  the  a xiomatizat ion  could  be  successfully 
completed.)  This  "experiment"  to  determine  the  utility  of  P3 
has  been  supplemented  by  the  following  more  formal  statement 
of  its  applicability: 

Theorem  7:  For  any  type  T=[ Cl (I)  ,S  +  0  ]  all  of  whose 
operations  are  primitive  recursive,  there  exists  an 
axiomatization ,  A,  such  that  A  is  r.s.c.(P3).  I.e.,  there 
exists  a  partitioning  of  S  into  disjoint  sets  C  and  NC  such 
that 

I)  For  all  cec  and  all  oeo,  the  term  o(c(x*),y*)  where 
x’*'  and  y*  are  free  is  safe,  and 

TI)  There  exists  an  ordering  of  the  functions  in  NC, 
f1,,,.,fm,  such  that  f1  is  convertible  to  C,  f2  is 
convertible  to  €■*■  {f1}  ,  etc. 
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the  proof ;  It  is  first  shown  that  it  is  possible 
to  construct  an  r.£.c.(R3)  specification  for  the  set  of 
basic  primitive  recursive  functions.  Call  the  type  with 
these  basic  functions  and  the  single  output  function 
?rQUAL?,  T=[ Cl  (I) ,S+0  ].  This  will  form  the  basis  of  an 
induction.  We  know,  by  definition,  that  any  primitive 
recursive  function  can  be  generated  from  the  members  of  S  by 
a  finite  number  of  applications  of  composition  and  primitive 
recursion.  We  will  assume  that  for  any  fm-1  €  Fm-1,  where 
Fm-1  is  the  set  of  primitive  recursive  functions  that  can  be 
constructed  using  m-1  applications  of  composition  and 
primitive  recursion,  there  exists  a  set  of  axioms  such  that 
■Pm-I  is  convertible  to  S+FI +Fm- 2 .  Finally,  using  this 
assumption,  it  is  shown  that  any  fmeFm  is  convertible  to 
S+F1 +. . . ♦Fm-2+Fm- 1 . 


of  2* 

1)  The  basic  primitive  recursive  functions  consist  of 
one  nullary  function  (call  it  ZEPO) ,  one  unary  function 
(call  it  SUCC) ,  and  an  infinite  number  of  projection  (or 
"pick  out")  functions.  Since  every  primitive  recursive 
function  can  be  constructed  using  only  a  finite  subset  of 
these  projection  functions,  however,  we  need  only  show  that 
any  (rather  than  all)  projection  function  can  be  specified. 
This  is  indeed  the  case,  since  any  axiom  of  the  form 
f  (x1 , . . . , xn) =xm,  1<m<n,  is  safe  if  feo,  or  obeys  constraint 
I  of  lemma  D  if  fes.  The  basic  type,  Prf,  for  the  primitive 
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recursive  functions,  vith  7EQUAL?  as  the  output  function, 
may  be  r.s.c,  (B3)  specified  as  follows: 

t ion s : 

ZERO:  ->  Frf 

SUCC:  Prf  ->  Prf 

7EQUAL?:  Prf  X  Prf  ->  Boolean 

Axioms : 

7EQUA1?  (ZERO, ZERO)  =  true 
7EQUAL7 (ZERO, SUCC  (X) )  =  false 
7EQUAL7  (SDCC  (X) , ZERO)  =  false 
7EQUAL7  (SUCC  (X)  ,SDCC(y) )  =  7FQUAL7(x,y) 

2)  Now,  assume  that  any  fm-ieFm-1  is  convertible  to 
S+F1-*-. . .  •fFm-2. 

3)  Consider  fmeFm.  fm  must  be  defined  by  either 

a)  fm(xO,x1,...,xn)=h(gC  (xO,...,xn)  ,...,gk(xO,..  .  xn)  )  , 
where  h,gO,.,.,gk  are  all  contained  in  S-«-F1  •»•... +Fm-1 ,  or 

b)  fm  (ZEP0,x1,.. .,xn)=g(x1,...,xn) 

f  m  (SUCC  (X)  ,x1,...  ,xn)=h(fm(x,x1,.,.,xn)  ,x,x1,...,  xn) 
where  g  and  h  are  contained  in  S  +  F1 , -•■Fm- 1 . 

Note  that  an  axiom  that  conforms  to  either  of  these 
forms  obeys  the  restrictions  outlined  in  lemma  D.  Thus  fm 
must  be  convertible  tc  S+ F1+. . . tFm- 1. 

g .  e.  d . 

There  are,  therefore,  a  large  number  of  abstract  types 
for  which  there  exists  an  axiomatization  than  is  r.s.c,  (R3). 

The  fact  that  the  conditions  outlined  above  are  purely 
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syntactic  means  that  P3  can  be  quite  simple.  It  also  means 
that  there  are  a  large  number  of  sufficient ly-complete 
axiomatiza tions  that  will  not  be  recognized  as  such.  In 
practice,  one  would  almost  certainly  wish  to  add  some 
primitive  rules  of  inference  to  any  procedure  designed  to 
check  for  sufficient-completeness.  One  would,  for  example, 
like  to  be  able  to  infer  the  safety  of  the  term 
7IQUAL?  (ZEPO, SDCC  (X) )  from  the  axioms 
ZIQUAl?  (x,y)  =?EQD;^L?  (y,x)  and  7FQDAI?  (SUCC  (x)  ,ZEPO)  =f alse. 
A  detailed  discussion  of  inference  techniques  is,  however, 
cutside  the  scope  of  this  thesis. 

An  examina+:ion  of  the  conditions  comprising  P3  leads  to 
an  informal  heuristic  ’’procedure”  that  has  proven  to  be 
useful  in  constructing  suff iciently-complete  axiomatizat ions 
of  abstract  data  types: 

1)  Partition  the  operations  of  the  type,  T=[I,S+0]  into 
the  sets  0,C,  and  NC  as  defined  above.  (Note  that  there  may 
be  several  such  partitionings.) 

2)  Build  the  set  CTEPMS  =  {c  (x 1 , . . . , xn)  |  c  is  an  n-ary 
function  €  C  and  ¥1<i<nrxi  is  a  free  variable]}. 

3)  Build  the  set  OTEPMS  =  {o  (x 1 , . . . , xn)  |  o  is  an  n-ary 
function  €  0  and  V1<i<n  {if  the  ith  argument  in  the  domain  of 
o  is  ei  then  xi  is  a  free  variable,  otherwise  xi€CTEF.MS]} 

4)  Build  the  set  NCTERMS  =  { nc  (x 1 , . . . , xn)  |  nc  is  an  n- 
ary  function  €NC  and  ¥1<i<n[if  the  ith  argument  in  the 
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domain  of  o  is  61  then  xi  is  a  free  variable,  otherwise 
xieCTERMS  ]}  . 

5)  Consider  a  type  T'=[I,C+0].  The  set  OTERMS  may  be 
used  as  a  set  of  left  hand  sides  in  constructing  a  safe 
axioma fization  of  T'.  Construct,  using  the  conditions  of 
theorem  4  for  guidance,  such  an  axiomatization . 

6)  Complete  the  axiomatization  of  T  by  adding  axioms 
that  demonstrate  the  convertibility  of  all  members  of  NC. 
The  members  of  NCTEEMS  form  a  sufficient  set  of  left  hand 
sides.  Theorem  5  may  be  used  for  guidance  in  supplying  the 
right  hand  sides. 


3.7.  Seme  remarks  on  consistency 

The  consistency  of  an  arbitrary  set  of  relations  is, 
like  completeness,  an  unsclvable  problem.  There  are, 
however,  many  techniques  that  are  sufficient  to  guarantee 
consistency.  Two  seem  particularly  germane  in  the  current 
context. 

The  construction  of  a  model  is  perhaps  the  most  widely 
used  technique  for  establishing  the  consistency  of  axiom 
sets.  To  show  that  an  axiomatization  of  an  abstract  type  is 
consistent,  it  is  sufficient  to  construct  a  provably 
"correct"  implementation  of  the  type.  (What  it  means  and 
how  to  go  about  proving  the  "correctness"  of  implementations 
of  abstract  types  is  discussed  in  each  of  the  next  two 
chapters.)  From  a  practical  point  of  view,  this  is  often  the 
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best  way  to  demonstrate  consistency.  If  the  abstract  t 
is  to  be  used,  an  implementation  must  eventually 
provided.  Hopefully,  a  proof  of  the  "correctness"  of  t 
implementation  will  also  be  provided  as  a  matter  of  cour 
If  this  is  the  case,  the  proof  of  consistency  comes  "fr 
as  a  side-effect.  The  danger  in  adopting  this  approach 
showing  the  consistency  of  a  specification  is  that  if 
specification  is  inconsistent,  it  is  possible  to  wa 
considerable  time  trying  to  build  a  model  that  cannot 
built.  This  problem  can  be  avoided  by  proving 
consistency  of  a  specification  before  trying  to  implem 
i-^.  One  way  to  do  this  is  to  demonstrate  that 
axiomatization  has  the  Church-Rosser  property  [Church  193 


The  conditions  for  establishing  suf f icient-ccmpleten 
presented  in  Section  3.6  were  based  upon  the  monotonicity 
the  axioms,  i.e.,  "="  was  not  treated  as  a  symmet 
relation.  What  was  actually  shown  was  that  the  conditi 
presented  are  sufficient  to  guarantee  that  for  any  t 
c  (x,y*) ,  o€C,  there  exists  a  series  of  reductions. 


o  (X, y*) ->z 1->z3->. . . ->z ,  where  z€Vi€I. 


Any  r.s.c.(K3)  axiomatization  may,  therefore,  be  viewed  a 
set  of  replacement  rules.  (Other  applications  in  which 
is  profitable  to  view  the  axioms  as  replacement  rules 
discussed  in  Sections  u. 3.  and  6.1.)  Thus,  for  any  s 
axiomatization,  consistency  may  be  demonstrated  by  prov 
that  the  set  of  replacement  rules  exhibits  the  Church-Ros 
property.  Informally,  a  set  of  replacement  rules  is  Chur 
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■Rcsser  if  whenever  one  applies  a  replacement  rule  to  reduce 
a  term,  and  then  a  rule  to  reduce  the  resulting  term,  etc. 
until  there  is  no  longer  an  applicable  rule,  the  final 
result  does  not  depend  upon  the  order  in  which  the  rules 
were  applied.  More  formally: 

•  If  s  term,  t,  can  be  reduced  to  another 
term,  t',  by  a  single  application  of  a  replacement  rule, 
t  hen  t->t '  . 

->*  is  the  reflexive  transitive  closure  of  ->. 

set  of  replacement  rules,  S,  is  Church- 
Rcsser  if  and  only  if 

Vt1,t2,t3ei(T)  [  (t1->=«'t2  &  t1->*t3)  implies  that 
there  exists  teL(T)  such  that  (t2->*t  8  t3->*t)  ]. 

There  are  many  ways  in  which  replacement  systems  may  be 
shown  to  be  Church-Fosser .  I  shall  not,  however,  discuss 
any  of  them  in  this  thesis.  The  interested  reader  is 
referred  tc  [Rosen  1973]  for  an  excellent  discussion  of  this 
subject. 
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4,  A  proof  of  the  correctness  of  a  representation 


This 

chapter  presents 

a 

rigorous  proof  of 

the 

correctne 

ss  of  a  representation 

of 

an  abstract  data  t 

ype 

Queue  (o 

f  Integers) ,  This 

is 

presented  not  because 

cf 

anything  unique  about  this  type  or  about  this  particular 


representation  of  it. 

but  rather 

as 

an 

example  of  the 

application  of  axiomatic 

specif icati 

ons 

cf 

abstract  data 

■*-ypes  to  proofs  of  co 

rrectness. 

It 

show 

s  how  one  may 

proceed  directly  and  algo 

r ithmically 

from 

the 

axiomat izat ion 

of  an  abstract  data  type  to  a  statement  of  what  it  means  for 
a  representation  of  that  type  to  be  correct.  It  also 
demonstrates  how  one  may  factor  a  proof  of  correctness  by 
assuming  the  correctness  of  representations  of  other  data 
types,  and  then  using  the  axioms  defining  those  data  types 
as  The  axioms  of  a  proof  system  (cf,  [Hcare  1972  ]). 
Finally,  it  indicates  that  much  of  this  kind  of  proof  is 
amenable  to  mechanization. 
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4.1,  The  problem 

The  problem  is  to  represent  type  Queue  (of  Integers)  in 
terms  of  a  simple  programming  language  which  includes  an 
"if”  statement,  an  assignment  statement,  and  the  operations 
defined  on  types  Vector,  Triple,  Natural  Number,  and 
Boolean;  and  to  prove  the  representation  correct.  Any  proof 
of  pregram  correctness  requires  three  things:  a  precise 

specification  of  how  the  program  is  supposed  to  behave,  a 
correct  program,  and  rules  of  inference  that  may  be  used  in 
deducing  the  program's  behaviour  from  the  pregram  text.  The 
first  and  most  of  the  last  of  these  are  supplied  by  the 
algebraic  type  specifications  below.  The  axiomatization  of 
type  Queue  (of  Integers)  defines  precisely  these  operations 
which  we  wish  to  represent.  The  remaining  type 
specifications  supply  the  semantics  for  most  of  the 
operations  used  in  the  representation.  The  meaning  of  the 
"if"  statement  is  the  common  one,  which  may  be  stated  (using 
Hoare's  notation)  as: 

(  {F&A}E  {Q}  )  S  (  {P8-.A}C  {Q})  implies  {P}  if  A  th^  E  else  C  {Q} 

Two  well-)?nown  [McCarthy  1962]  properties  of  this  statement 
shall  be  used  without  recourse  to  a  formal  proof  of  *heir 
valid ity : 

”• )  (if  ^  ®  D,  is  equivalent 

t o  if  A  then  B  else  D . 

2)  F  (if  then  B  else  C)  is  equivalent  to  if  A  then 


B  (E)  else  F  (C) 
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Type  Queue 


Operations : 

EMPTY. Q: 
ADD.Q: 
PEMOVE.Q: 
FEONT. 0: 
7EMPTY.Q?  : 


Axioms : 

Q1)  7EMPTY.  Q?  (EMPTY.  Q)  =  true 
02)  7EMPTY. Q7  (ADD. Q  (g,i) )  =  false 
Q3)  FRONT. Q  (EMPTY. Q)  =  error 
Q4)  FRONT.  Q  (ADD.  0  (q,  i)  )  = 

if  7EMFTY. Q7 (q) 
then  i 

else  FRONT.  Q(q) 

Q5)  REMOVE. Q  (EMPTY. 0)  =  error 
Q6)  REMOVE.  Q  (ADD.  0  (q,  i)  )  = 

if  7EMFTY.Q7 (q) 

then  EMPTY. 0 

else  ADD. Q(REMOVE. Q (q) ,i) 


->  Queue 

Queue  X  Integer  ->  Queue 
Queue  ->  Queue 
Queue  ->  Integer 
Queue  ->  Boolean 
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Natural  Number 


ZFRO: 

SDCC: 

?ZERO?: 

? EQUAL?: 

. 


->  Natural  Number 
Natural  Number  ->  Natural  Number 
Natural  Number  ->  Boolean 

Natural  Number  X  Natural  Number  ->  Boolean 
Natural  Number  X  Natural  Number  ->  Boolean 


N1)  ?ZEFO?(ZEPO)  =  true 

N2)  7ZEP0?  (STJCC(r.)  )  =  false 

N3)  7EQUAL? (ZERO, ZERO)  =  true 

N4)  7EQUAL? (SUCC (n) , ZERO)  =  false 

N5)  7EQUAL?  (ZERO, SUCC (n) )  =  false 

N6)  7EQDAI?  (SUCC (n)  , SUCC  (n1) )  =  7EQUAL?  (n , n1 ) 

N7)  ?>?  (ZERO , ZERO)  =  false 

N8)  ?>? (SUCC (n) , ZERO)  =  true 

N9)  ?>?  (ZEPO,SUCC(n)  )  =  false 

N10)  ?>?  (SDCC  (n)  , SUCC  (n1)  )  =  ?>?(n,n1) 


(To  those  brought  up  on  the  Peano  axioms  the  size  of  the 
above  specification  may  seem  a  bit  alarming.  The  extra 
axioms  are,  however,  completely  attributable  to  the  explicit 
a xiom atizaticn  of  various  functional  extensions,  see  Section 
3.6.  ) 

In  addition  to  the  above  axioms,  the  proofs  to  follow 
make  use  of  four  theorems  derivable  from  these  axioms; 


Theorem 

1' 

7EQUAL?  (n 

,n1)  implies  ?>?  (SUCC  (n)  ,n1) 

Theorem 

2; 

?>?(n,n1) 

implies 

?>?  (SUCC  (n)  ,n1) 

Theorem 

3: 

?>?  (n,n1) 

implies 

7EQUAL?  (n,n1) =false 

Theorem 

H' 

?>?(n,n1) 

implies 

(7EQDAL? (n, SUCC  (n1) )  or 

?>?  (n  ,SDCC  (n1)  ) ) 
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Il£§  Vector 


0  cerat ion  s 


FMPTY. V: 
ASSIGN: 
FEAD: 
7EHPTY. V? 


->  Vector 

Vector  X  Index  X  Item  ->  Vector 
Vector  X  Index  ->  Item 
Vector  ->  Boolean 


Axioms 


VI)  7EMPTY.V?  (EMPTY. V)  =  true 
V2)  7EMPTY.V7 (ASSIGN  (V, in , it) )  =  false 
V3)  HEAD  (EMPTY. V, in)  =  error 
VU)  HEAP (ASSIGN(v,in1 ,it)  ,in2)  = 

if  7EQUAL7 (ini , in2)  /*as  defined  for  the  index  type*/ 
then  it 

else  BEAD  (V, in 2) 


Type  Triple 


BUILD:  Itema  X  Itemb  X  Itemc  ->  Triple 


EIEST:  Triple  ->  Itema 
SECOND:  Triple  ->  Itemb 
THIRD:  Triple  ->  Itemc 


Axioms : 


T1)  FIRST (BUILD(i,i1, i2) )  =  i 

T2)  SECOND  (BDIID (i,i1 ,i2) )  =  i1 
T3)  THIRD(EUILD(i,i1,i2)  )  =  i2 

(Note  that  in  most  languages  TRIPLE  would  be  treated  as 
a  data  structure  (record) .  In  keeping  with  the  subject  of 
this  thesis,  however,  I  have  chosen  to  treat  it  as  a  type  in 
order  to  avoid  an  unnecessary  digression.  Nevertheless,  it 
will  serve  as  the  storage  structure  component  of  the 
representation,  see  Section  1.1.) 


-90- 


4.2.  Ths  representation 


k  representation  of  a  type  T  =  [CL(I),S+0]  consists  of: 

1)  any  interpretation  cf  the  operations  contained  in  S+0 
that  is  a  model  for  the  axioms  of  the  specification  of  T 
(This  interpretation  incorporates  borh  the  storage  structure 
and  the  set  of  operations  referred  to  in  Section  1.1.), 

2)  a  function,  5,  that  maps  terms  in  the  model  domain 
onto  their  representatives  in  the  abstract  domain. 

It  is  important  to  none  that  a  may  not  have  a  proper 
inverse.  Consider,  for  example,  type  Bounded  Queue  (with  a 
maximum  length  of  three) .  A  reasonable  representation  cf 
the  values  of  this  type  might  be  based  on  a  ring-buffer  and 
tcp  pointer.  Given  this  representation,  the  program  segment 


X  :=  EMPTY. Q 
X  :=  ADD.  Q  (x,A) 

X  :=  ADD.  Q  (X  ,E) 

X  :=  ADD.Q(x,C) 

X  :=  REMOVE. Q(x) 

X  :=  ADD. Q  (X, D) 

would  translate  to  a  representation  of  the  form: 


Tcp  Pointer 

I 

->  l_E_l  ->  l_C_| 
I _ 


-> 


I 


Similarly : 
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X  :=  EMPTY. Q 
X  :=  APD.  Q  (X  ,E) 

X  :=  ACD.  Q  (x,C) 

X  :=  ADD.  Q  (x,D) 

would  yield  a  representation  of  the  form: 

Top  Pointer 

I 

->  l_C_|  ->  |_D_|  -> 

It  is  clear  that  these  two  representations,  though  not 
identical,  refer  to  the  same  abstract  value.  That  is  to 
say,  the  mapping  from  values  to  representations,  ,  may  be 
one- to- many. 

The  overall  scheme  of  the  following  representation  of 
type  Queue  (of  Integers)  is  to  represent  a  queue  as  a  triple 
in  which  the  first  element  is  a  vector,  the  second  element  a 
natural  number  giving  the  index  into  the  vector  of  the  next 
element  to  be  added  to  the  queue,  and  the  third  element  the 
index  of  the  element  that  is  the  current  head  of  the  queue. 
Thus  5  has  domain  Triple  and  range  Queue.  For  every 
function,  ?,  in  the  domain  of  queues,  we  define  a  function, 
F',  in  the  domain  of  the  representation  such  that 
EMPTY. Q=5  (EMPTY. Q') f  ADD. Q  (5  (x)  ,y) =5  (ADD. Q*  (X, y) )  ,  etc.  We 
thus  get  the  following  functions  with  the  indicated  domain 
and  range  types; 
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EMPTY '  : 

->  Triple 

ADD*  : 

Triple  X  Integer  ->  Triple 

EEMOVE* : 

Triple  ->  Triple 

FRONT' : 

Triple  ->  Integer 

7EMPTY?' 

;  Triple  ->  Boolean 

The  ’’code”  for  each  of  the  functions  is  should  be  read 

”is  defined  as. ”) ; 

EMPTY'  ::  EDILD  (EMPTY. V, ZIPO, ZEPO) 


ADD*  (A,B)  :  : 

BUILD (ASSIGN  (FIRST  (A)  , SECOND  (A)  ,B)  , 

SUCC  (SECOND  (A) ) , THIRD (A) ) 

REMOVE' (A) : : 

if  7EQDAL7 (SECOND  (A)  , THIRD  (A) ) 

then  error 

else 

if  7E0UAL7  (SECOND  (A)  ,SUCC  (THIRD  (A) )  ) 

then  EMPTY' 

else  BUILD  (FIRST (A)  , SECOND  (A)  , SUCC (THIRD(A) ) ) 

FRONT '  (A)  : : 

if  7EQUAL7  (SECOND  (A)  , THIRD  (A) ) 

then  error 

else  READ (FIRST (A)  , THIRD  (A) ) 

7EMPTY?'  (A)  : 

:  7EQUAL7  (SECOND  (A)  , THIRD  (A) ) 

The  five  mappings  below  define  2  for  the  representation 
chosen  for  type  Queue  (of  Integers) .  Mappings  a,  b,  and  d 
are  quite  straightforward,  and  should  pose  no  problem  ro  the 
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reader.  The  conditionals  of  mappings  c  and  e  were 
introduced  to  insure  that  any  A  for  which  ?EMPTY?'(A)  =  true 
will  be  mapped  to  the  representative  value  EMPTY'.  Mapping 
e  also  ensures  that  all  abstract  values  will  be  in  a 
canonical  form:  a  series  of  ADD's  nested  inside  a  series  of 
EEMOVE's.  Note  that  we  needn't  worry  about  the  error 
condition  in  which  there  are  more  PEMOVE's  than  ADD's.  We 
need  worry  only  about  valid  representations.  All  other 
possibilities  are  taken  care  of  by  mapping  a. 


a)  S (error)  =  errcr 

b)  S (BUILD (EMPTY. V, ZEBO, ZERO) )  =  EMPTY. Q 

C)  5  (BUILD  (FIRST (A)  , SECOND  (A)  ,SUCC  (THIRD  (A) ) ) ) 

=  if  7EQUAL?  (SECOND (A)  ,SUCC (THIRD  (A) ) ) 
then  EMPTY.  Q 
else  REMOVE. Q  (®  (A) ) 

d)  5  (BUILD  (ASSIGN (FIRST (A) , SECOND (A)  , B)  , SUCC (SECOND (A) )  , 

THIRD  (A)  )  ) 

=  ADD.O  (3  (A)  ,E) 

e)  5  (BUILD  (ASSIGN (FIRST  (A) , SECOND (A)  , B)  , SUCC (SECOND (A) )  , 

SUCC  (THIRD  (A)  )  )  ) 

=  if  7FQUAL?  (SECOND (A)  , SUCC (THIRD (A) ) ) 
then  ADD. Q  (EMPTY. Q,E) 
else  REMOVE. Q  (ADD  (ffi  (A)  ,B) ) 
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4.3.  The  proof  of  correctness 


In  the  course  of  this  proof  two  kinds  of  invariants  will 
be  verified:  inherent  invariants  and  representation 
invariants.  The  inherent  invariants  represent  those 
invariant  relationships  that  must  be  maintained  by  any 
representation  of  the  type.  They  correspond  to  the  axioms 
used  in  the  specification  of  the  type.  A  representation 
invariant,  on  the  other  hand,  is  peculiar  to  a  particular 
representation  of  a  type.  Lemma  A  below  is  such  an 
invariant . 


The  basic  procedure  followed  in  verifying  the  inherent 
invariants  is  to  take  each  axiom  for  type  Queue  (of 
Integers) ,  and  replace  all  instances  of  each  function 
appearing  in  the  axiomatiza t ion  with  its  interpretation. 
Then,  using  the  axiomatiza tions  of  the  operations  used  in 
constructing  the  representations,  it  is  shown  that  the  left 
hand  side  of  each  axiom  is  equivalent  to  the  right  hand  side 
of  that  axiom.  That  is  to  say  they  represent  the  same 
abstract  value. 


What  must  be  shown,  therefore,  is  that  for  every  axiom, 
f ' (X*)  =z,  derived  from  the  axiomatization  of  type  Queue  (of 
Integers),  either 

1)  f€S  and  ffi(f'(x^))  =  5(z)  for  all  legal  assignments  to 
the  free  variables  of  x*  and  z,  or 

2)  feo  and  f* (x*)  =  z  for  all  legal  assignments  to  the 
free  variables  of  x*  and  z. 
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Tc  show  this,  we  have  at  our  disposal  a  proof  system 
consisting  of  the  rules  of  inference:  (A=B  &  B=C)  implies 

A=C,  (P=true  8  C=if  P  then  else  B)  implies  C=A,  and 

(P=false  8  C=if  P  then  A  else  B)  implies  C=B;  and  the  axioms 
defining  the  operations  used  in  the  representation. 

The  proofs  below  depend  upon  the  assumption  that  objects 
of  type  Queue  are  created  and  manipulated  only  via  the 
operations  defined  in  the  specification  of  that  type. 
Therefore,  all  that  need  be  shown  is  that  if  on  entry  to  an 
operation  all  invariants  hold  for  all  objects  of  type  Queue 
to  be  manipulated  by  that  operation,  then  all  invariants  on 
those  objects  hold  upon  completion  of  that  operation.  The 
proof  begins  with  a  representation  invariant: 

( 

Lemma  A:  For  any  triple.  A,  representing  a  queue,  either 
7FQUAL? (SECOND  (A)  ,THIPD  (A) )  or  ?>?  (SECOND  (A)  , THIRD  (A)  )  . 

Zioof •  (2y  induction  on  depth  of  operator  nesting): 

1)  If  A=EMFTY*,  then  SECOND (A) =THIED  (A) =ZERC,  and 
7EQUAL? (ZERO , ZERO)  is,  by  axiom  N3,  true. 

2)  Assume  that  the  lemma  is  true  for  an  arbitrary 
queue,  A. 

We  now  consider  each  operator  individually: 

3)  ADD*  (A,B)  =  BUILD  (ASSIGN (FIRST (A)  , SECOND  (A)  ,E)  , 

SUCC  (SECOND  (A)  )  , THIRD  (A)  )  . 


Thus,  by  axioms  T2  and  T3, 
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SECOND  (ADD*  (A,E)  )  =SUCC  (SECOND  (A)  )  and  THIED(ADD'  (A,E)  )  =THIBD(A)  . 
S*ep  2  ensures  that  either  ?EQ UAL?  (SECOND  (A) , TRIED (A) )  cr 
?>? (SECOND  (A) , TRIED (A) )  .  Thus,  by  theorems  ^  and  2  for  type 
Natural  Number,  ?>? (SUCC (SECOND  (A) ), TRIED  (A) )  . 

4)  EEMOVE*  (A)  has  three  subcases: 

If  7EQUAL? (SECOND (A) , TRIED (A) ) ,  then  EENOVE'(A) 
equals  error.  So  the  lemma  is  vacuously  true. 

If  7EQUAL? (SECOND (A)  , SUCC  (THIRD (A) )  ,  then 

REMOVE'  (?^-)  =  EMPTY'.  So,  by  step  1, 

7EQUAL?  (SECOND  (REMOVE'  (A)  )  , TRIED  (REMOVE'  (A) ) )  . 

If  neither  of  the  above  is  true,  REMOVE' (A)  = 
BUILD  (EIFST  (A)  , SECOND (A)  , SUCC  (TRIED  (A) )  .  By  step  2  and  the 
fact  that  7E0UAL?  (SECOND (A)  , TRIED  (A) )  =  false  (it  was  tested 

above),  we  know  that  ?>?  (SECOND  (A)  , TRIED  (A) )  .  Thus,  by 
theorem  4,  ?>?  (SECOND (A)  , SUCC (TRIED (A) ) )  =  true 

q. e. d. 


from  this  representation  invariant  we  derive  a  second 
represent  at ion  invariant: 

Lemma  E:  For  any  triple.  A,  representing  a  queue, 

7EQUAL?  (SUCC (SECOND (A) ), TRIED (A) )  =  false. 

Proof : 

1)  From  lemma  A  we  know  that  either 
7EQDAI? (SECOND  (A)  , TRIED  (A) )  or  ?>?  (SECOND  (A)  , TRIED  (A)  )  . 

2)  Thus,  by  theorems  1  and  2,  ?>?  (SUCC  (SECOND  (A) )  ,TRIPD(A) )  . 
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3)  Thus,  by  theorem  3, 

7EQUAL? (SUCC  (SECOND(A)  )  ,THTPD  (A) )  =  false. 

^  .  e  •  d  • 

Turning  now  to  the  inherent  invariants,  each  axiom  from 
the  specification  of  type  Queue  (of  Integers)  is  examined  in 
turn.  The  basic  procedure  is  tc  first  substitute  in  the 
interpretations,  then  reduce  both  sides  of  the  axiom  as  far 
as  possible  through  the  "forward”  application  of  lemmas, 
theor-=ms,  and  type  axioms  (as  discussed  in  Section  3.7.). 
After  this  has  been  done  5  is  applied  (perhaps  implicitly) 
tc  both  reduced  terms  to  show  that  the  left  and  right  hand 
sides  are  indeed  equivalent. 

Verification  of  Axiom  21* 

Dees  7EWPTY?*  (EMPTY*)  =  true  7 

Replacing  7EMPTY7*  and  EMPTY*  with  their  representations  yields 

7EMPTY7*  (EMPTY*)  =  7EQUAL7  (SECOND  (BUILD (EMPTY. V , ZERO, ZERO) )  , 

THIRD  (BUILD (EMPTY. V, ZERO, ZERO)  ) ) 

Which,  by  axioms  T2  and  T3, 

=  7EQUAL7 (ZERO, ZERO) 


Which,  by  axiem  N3, 


true 
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Verif icat ior  of  Axiom  Q2 

Dees  7EMPTY?'  (A.DD  •  (A,B)  )  =  false  ? 


TEMPTY?*  (Af B)  )  = 

7EQUA.L?  (SECOND  (BU ILD  (ASSIGN  (FIPST  (A)  ,  SECOND  (A)  ,B)  , 

SOCC (SECOND (A) )  , THIRD  (A) )  , 
THIRD  (BUILD  (ASSIGN (FIRST (A)  , SECOND  (A)  ,B)  , 
SUCC  (SECOND  (A)  )  ,  THIRD  (A)  )  ) 

Which,  by  axioms  T2  and  T3, 


=  7EQDAL7  (SUCC  (SECOND  (A) )  , THIRD  (A) ) 


Which,  by  lemma  B, 


=  false 


V erif i ca t i cn  of  Axiom  Q3 : 

Does  FRONT*  (EMPTY')  =  error  7 

FRONT  *  (EMPTY* )  =  READ (FIR  ST (BUILD (EMPTY. V , ZERO, ZERO) )  , 

THIRD  (BUILD  (E MPT Y . V , ZERO , ZERO)  )  ) 

Which,  by  axioms  T1  and  T3, 

=  READ (EMPTY. V , ZERO) 

Which,  by  axiom  V3, 


error 
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Verifi cation  of  Axiom 


Does  FPONT*  )  = 

if  7EMFTY? '  (A) 


then  B 

else  FBCNT'(A)  ? 


Looking  first  at  the  left  hand  side: 


^FONT  '  (ADC  (A,P)  )  =  HEAD  (FIFST  (EUIL  E  (AS  SI  GN  (FIRST  (A)  ,  SECOND  (A)  ,E)  , 

SUCC  (SECOND  (A)  )  ,  THIPD  (A)  )  , 
THIFD(BUILD(ASSIGN  (FIFST  (A)  ,  SECOND(A)  ,  B)  , 

SDCC  (SECOND  (A)  )  ,  THIRD  (A)  )  ) 


Which,  by  axioms  T1  and  T3, 


=  READ  (ASSIGN  (FIRST (A)  , SECOND  (A)  ,B)  , THI RD (A) ) 


Which,  by  axicra  V4, 


=  if  ?EQ UAL?  (SECOND  (A)  ,  THIRD  (A)  ) 
t hen  B 

else  READ (FIRST  (A)  , THIRD  (A) ) 
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Lcoking  now  at  the  right  hand  side  of  the  axiom: 

if  7EMPTY?' (A) 
then  E 

else  FBONT' (A) 

=  if  7EQTJAL?  (SECOND  (A)  ,  TRIED  (A)  ) 
then  E 

else  if  7EQUAL?  (SECOND  (A)  ,THIF,B  (A)  ) 
then  error 

else  READ  (FIRST (A)  , TRIED (A)  ) 

Which,  because  the  two  Boolean  conditions  are  identical, 

=  if  7EQnAL7  (SECOND (A)  , THIRD  (A) ) 
then  B 

else  READ (FIRST (A)  , THIRD  (A) ) 

q ,  e. d  , 
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Ver if i cation  of  Axiom  : 

Does  5  (RFWCVE  •  (FKFTY' )  )  =  5(error)  ? 

Substituting  in  the  representation  of  EMPTY', 

S  (REMOVE'  (EMPTY' ) ) 

=  £(EEMOVE' (EMPTY. V, ZERO, ZERO)) 

Which,  substituting  in  the  representation  of  REMOVE'  and 
applying  axioms  T2  and  T3, 

=  S(if  7E0UAL? (ZERO, ZERO) 
then  error 

5lse  if  7EQDAL?  (ZERO, SUCC (ZERO)  ) 
then  EMPTY' 

else  FDILD (EMPTY. V , ZERO, SUCC  (ZERO) ) ) 

Py  axiom  N3,  7EQUAL7 (ZERO , ZERO)  =  true.  Therefore, 

=  ffi(error) 


q .  e.  d 
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Verification  of  Axiom  £6: 

Does  ffi  (REMOVE*  )  )  = 

if  ?EMPTY?*(A) 
then  5  (EMPTY*) 

else  S  (;^DD*  (REMOVE*  (A)  ,  E)  )  ? 

Looking  first  at  the  left  hand  side: 

S  (REMOVE*  (?iDD*  (A,E)  ) 

=  5(FEM0VE*  (BUILD  (ASSIGN  (FIRST  (A)  ,SECOND(A)  ,E)  , 

SUCC  (SECOND  (A)  )  , THIRD  (A)  )  )  ) 

Which,  subst it uning  in  the  representation  of  REMOVE*  and 
applying  axioms  T2  and  T3, 

=  a (if  7FQDAL? (SUCC(SECOND  (A)  )  ,THIRD  (A) ) 
then  error 

Sise  if  7FQUAL?  (SUCC  (SECOND (A) ), SUCC (THIRD (A)  )  ) 
then  EMPTY* 

else  EUILD  (ASSIGN (FIRST (A)  , SECOND (A)  , B)  , 

SUCC  (SECOND  (A)  )  ,SUCC  (THIRD  (A)  )  )) 

By  lemma  B,  7EQUAL? (SUCC  (SECOND  (A) ), THIRD  (A) )  =  false.  By 

applying  axiom  N6,  7FQDAL7 (SUCC  (SECOND  (A) )  , SUCC  (THI HD  (A) ) ) 
can  be  reduced  to  7EQDAL?  (SECOND (A) , THIRD  (A) ) .  Which, 
removing  the  unreachable  case,  substituting  in  the 
representation  of  EMPTY*,  and  moving  S  inward. 
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=  if  7EQUAL?  (SECOND  (A)  , THIRD  (7^)  ) 

then  S  (ETJILD  (EMPTY.  V,  ZERO, ZERO)  ) 

else  5  (BUILD  (ASSIGN  (FIRST  (A)  ,  SECOND  (A)  ,E)  , 

SUCC  (SECOND  (A) )  , SDCC (THIRD  (A) )  )  ) 

Which,  applying  mappings  b  and  e  and  axioms  T2  and  T3, 

=  if  7EQUAL?  (SECOND  (A)  , THIRD (A) ) 
then  EMPTY. Q 

il  ?FQTJAL7  (SECOND  (A)  , SUCC  (THIRD  (A)  )  ) 
then  ADD. Q  (EMPTY. Q,B) 
else  REMOVE  (ADD. Q  (a  (A)  ,B) 

Turning  now  to  the  right  hand  side: 

if  7EMPTY7' (A) 
then  5 (EMPTY') 
else  5 (ADD*  (REMOVE'  (A)  , E)  = 

if  7E0UAL7 (SECOND (A) , THIRD (A)) 

then  5  (BUILD (EMPTY. V, ZERO, ZERO)  ) 
else  S  (ADD'  (REMOVE'  (A)  ,  E)  ) 


Which,  substituting  in  the  representation  of  REMOVE', 
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=  if  7EQUAL?  (SECOND  (A)  , TRIED  (Ji)  ) 

then  5  (BUILD  (EMPTY.  V,  ZERO, ZERO)  ) 

else  3  (ADD*  (if  7EQUAL?  (SECOND  (A)  , TRIED  (A)  ) 

then  error 

€lSf  if  7EQUAL7  (SECOND  (A)  ,SUCC  (TRIED  (A)  )  ) 
then  BUILD (EMPTY. V, ZERO, ZERO) 
else  BUILD  (FIRST  (A)  , SECOND (A)  , 

SUCC  (TRIED  (A) ) )  , B) ) 

Removing  the  redundant  clause,  moving  ADD'  inward,  and 
substituting  in  its  representation, 

=  if  7E0UAL7  (SECOND  (A)  , TRIED  (A) ) 

then  5  (BUILD (EMPTY. V, ZERO, ZERO)  ) 

f;lse  £  (if  7EQDAL7  (SECOND  (A)  ,  SUCC  (TRIED  (A)  )  ) 

then  BUILD  (ASSIGN  (EMPTY.  V, ZERO, B)  ,  SDCC(ZEEO)  ,ZEEO 
else  BUILD  (ASSIGN  (FIRST (A)  , SECOND  (A)  ,B)  , 

SUCC  (SECOND (A) )  , SUCC  (THIRD (A) ) )  ) 

Which,  applying  mapping  b  to  the  outer  then  clause,  moving 
the  5  of  the  outer  else  clause  inward,  and  then  applying 
mapping  d  to  the  inner  then  clause,  and  mapping  e  to  the 
inner  else  clause. 
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=  if  7EQUAL?  (SECOND  (A)  , THIRD  (;\)  ) 
then  FNPTY.Q 

if  7EQUAL? (SECOND (A)  ,SUCC (THIRD  (A) ) ) 
then  ADD. Q  (3  (EMPTY .V ,ZERO,ZERO)  , E) 
else  if  7EQUAL7 (SECOND  (A)  , SUCC  (THIPD  (A) ) ) 
then  ADD. Q  (EMPTY. Q,E) 
else  REMOVE  (ADD.  Q  (S  (A)  ,B)  ) 

Which,  applying  mapping  b  and  removing  the  redundant  clause, 

=  if  7EQUAL7  (SECOND  (A)  , THIRD  (A)  ) 
then  EMPTY. 0 

else  if  7EQUAL7  (SECOND  (A)  ,SDCC  (THIRD  (A) ) ) 
then  ADD. Q  (EMPTY. C,E) 
else  REMOVE  (ADD.  Q  (5  (A)  ,B)  ) 

Which  is  the  same  expression  to  which  the  left  hand  side 
of  this  axiom  was  reduced.  This  completes  the  proof  of  the 
correctness  of  the  representation. 


4.ii.  Seme  remarks  about  the  proof 

At  first  glance,  the  above  proof  may  appear  to  be  rather 
complex.  However,  while  it  may  indeed  be  somewhat 
cumbersome,  it  is  basically  quite  simple.  The  assertions  to 
be  verified  can  be  mechanically  produced  by  a  simple 
algorithm.  Many  of  the  reductions  can  also  be  done 
algorithmically.  The  removal  of  redundant  "then”  or  "else" 
clauses,  for  example,  is  a  feature  commonly  found  in 
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optimizing  compilers,  and  the  reduction  of  terras  that  do  not 
contain  free  variables  is  almost  identical  to  the  problem 
solved  by  the  simulator  system  to  be  discussed  in  Section 
6.  1.  Both  the  thoroughness  and  the  speed  with  which  this 
can  be  done  depends,  of  course,  on  one's  willingness  to 
restrict  the  kinds  of  axiomatizat ions  to  be  processed. 

The  most  "creative"  step  in-  the  proof  was  the 
introduction  of  lemma  2,  Even  here,  however,  the  creativity 
involved  was  minimal.  When  I  started  work  on  this  proof,  I 
did  not  begin  with  such  a  lemma.  It  was  only  when  forced  to 
prove  (while  verifying  that  axiom  2  was  satisfied  by  the 
representation)  that  ?FQ UAL? (SUCC (SECOND  (A) ), THIRD  (A) )  was 
false  that  it  became  apparent  that  the  representation,  if  it 
were  correct,  had  to  preserve  the  invariant  embodied  in 
lemma  2,  Thus  I  had  only  to  prove  the  invariant  condition, 
net  to  discover  it. 

It  should  be  noted  that  the  above  proof  took  place 
almost  entirely  within  the  domain  of  abstract  types.  In  a 
"real-world"  environmenr  it  will  often  be  necessary  to 
construct,  at  some  level  of  refinement,  a  representation 
based  upon  the  primitives  of  a  more  conventional  programming 
language.  At  that  point  a  proof  of  correctness  would 
necessarily  involve  the  proof  rules  for  that  language,  e, g. , 
those  contained  in  [ Hoare  1973],  In  some  cases  there  may  be 
a  gap  between  the  lowest  level  rhat  it  is  convenient  to 
specify  via  abstract  types  and  the  actual  programming 
language  implementation.  One  might,  for  example,  wish  to 
refine  the  actual  storage  structure  in  several  steps.  A. 
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5.  Algebraic  type  specification  as  a  design  tool 

5.1.  Some  preliminaries 

Brooks  [1975]  calls  top-down  design  ([Wirth  1971], 
[Dijkstra  1972  ])  "the  most  important  new  prcgrammir.g 
formalization  of  the  decade."  Whether  or  not  one  chcoses  to 
accept  Brooks’s  evaluation  at  face  value,  in  is  indisputable 
that  the  concept  of  top-down  design  (also  known  as  stepwise 
refinement  and  successive  decomposition)  is  having  an 
important  effect  on  the  manner  in  which  software  is  designed 
(‘=“.g.,  [Baker  1972  ]  and  [wills  1  973  ]).  The  technique  is 
based  upon  the  development  of  a  series  of  refinement  steps. 
The  programmer  or,  in  the  case  of  larger  projects,  the 
system  designer  begins  with  an  extremely  abstract  solution 
tc  his  problem.  Various  components  of  this  solution  are 
then  identified  as  separable  problems,  and  slightly  less 
abstract  solutions  are  constructed  for  each  of  them.  In 
this  way  a  series  of  increasingly  less  abstract 
representations  of  the  solution  is  constructed.  Eventually, 
one  reaches  a  point  at  which  all  components  of  the  original 
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solution  have  compiler  translatable  representations.  At 
this  point  the  process  is  complete. 

The  virtues  of  a  good  top-down  design  are  many.  The 
partitioning  of  each  refinement  into  independent  modules 
reduces  the  connectivity  of  the  system  or  program,  thus 
isolating  the  effects  of  errors  in  design  or  implementation. 
This  modularity  also  leads  to  software  that  is  more  easily 
adapted  to  other  uses  and  more  amenable  to  changes  aimed  at 
increasing  efficiency.  The  suppression  of  irrelevant  detail 
in  each  refinement  makes  the  refinement  easier  to  read  and 
u nder stand.  It  should  thus  be  easier  to  detect  problems  in 
the  design.  Once  a  problem  is  detected,  the  hierarchical 
structure  of  the  design  simplifies  the  job  of  discovering 
which  modules  may  be  affected  by  the  problem. 

The  key  to  successful  top-down  design  is  the  ability  to 
construct,  at  each  level  of  abstraction,  refinements  that 
suppress  all  irrelevant  detail  while  clearly  exposing  the 
relevant  concepts  and  structure.  By  deferring  detail,  the 
number  of  decisions  that  must  be  made  at  any  one  time  is 
reduced.  Verifying  the  correctness  of  each  refinement  as  it 
is  developed  is  crucial.  It  enables  one  to  "correct"  errors 
as  they  are  made  rather  than  forcing  one  to  resort  to  the  ex 
£211  facto  "patching  of  partially  correct  programs..." 
[Fenderson  1972],  Therefore,  the  specification  of  a 
refinement,  though  possibly  quite  abstract,  must  be  complete 
and  unambiguous.  All  symbols  that  appear  in  it  must  be 


well-defined 
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or  a  symbol  to  be  well-defined,  its  exact  meaning  must 
r  be  known  a  priori  or  be  supplied  elsewhere  in  the 
fication.  In  most  cases,  to  use  only  symbols  whose 
nos  are  a  priori  known  will  prove  self-defeating.  If 
exists  a  special-purpose  description  language  that  is 
priate  to  the  problem  with  which  one  is  grappling 
,  if  one  is  dealing  with  a  set-theoretic  problem) ,  one 
manage  to  construct  an  adequate  specification 

ining  only  generally  understood  symbols, 

tunately,  this  is  rarely  the  case.  And  if  it  is  not, 
attempt  to  use  only  symbols  whose  meaning  is  known  a 
i  will  lead  to  a  rather  low-level  abstract 


fication.  It  will  be  too  lengthy  to  be  perspicuous, 
xtremely  inflexible.  In  short,  it  will  have  all  of  the 
eras  associated  with  operational  specifications  (see 
on  2.2).  One  is  thus  forced  to  introduce  new  abstract 
Is  (generally  operations  and  data  objects)  whose 
ng  will  have  to  be  defined. 


The  introduction  of  new  operations  and  the  introduction 
of  new  data  objects  are  inextricably  bound.  If  one 
introduces  a  new  type  of  data  object,  it  becomes  useful  only 
when  one  has  supplied  operations  in  which  objects  of  that 
type  may  play  a  role.  If  one  introduces  a  new  operation, 
one  must  either  introduce  a  new  data  type  or  augment  the 
definition  of  an  old  data  type  by  explaining  the  interaction 
of  objects  of  that  type  with  the  new  operation. 
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Sc,  one  is  always  dealing  with  a  set  of  values  and  a  set  of 
operations,  i.e.  ,  precisely  the  sort  of  algebraic  system 
That  I  have  called  an  abstract  data  type.  An  example  should 
help  to  clarify  the  way  in  which  algebraic  type  definitions 
may  be  used  ro  facilitate  the  process  of  top-down  design. 


5.2,  An  example 

A  common  data  structuring  problem  is  the  design  of  the 
symbol  table  component  of  a  compiler  for  a  block  structured 
lanauage.  [Cries  1971],  [ McKeeman  1974],  [Aho  1973],  and 
many  other  sources  contain  good  discussions  of  various 
symbol  table  or ganiza-*- ions.  Setting  aside  variations  in 
form,  the  basic  operations  described  vary  little  from  source 
to  source.  They  are: 

INIT;  Allocate  and  initialize  the  symbol  table. 

ENTERELOCK;  Prepare  a  new  local  naming  scope. 

lEAVEElOCK:  Discard  entries  from  the  most  recent  scop^ 

entered,  and  reestablish  the  next  outer  scope. 

7INEL0CK?:  Has  a  specified  identifier  already  been 

declared  in  this  scope?  (Used  to  avoid  duplicate 
declarations. ) 

ADD:  Add  an  identifier  and  its  attributes  to  the  symbol 


table 
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PETRIEVE:  Return  the  attributes  associated  (in  the  most 

local  scope  in  which  it  occurs)  with  a  specified  identifier. 

Though  each  reference  cited  provides  insights  into  how 
these  operations  can  be  implemented,  none  presents  a  formal 
definition  (other  than  implementations)  of  exactly  what  they 
mean.  The  abstract  concept  ’’symbol  table”  thus  goes 
undefined.  Those  who  attempt  to  write  compilers  in  a  top- 
down  fashion  suffer  from  a  similar  problem.  Early 

refinements  of  parts  of  the  compiler  make  use  of  nhe  basic 
symbol  table  operations,  but  the  ’’meaning”  of  these 
operations  is  provided  only  by  subsequent  levels  of 
refinement.  This  is  infelicitous  in  that  the  clear 
separation  of  levels  of  abstraction  is  lest,  and  with  it 
many  of  the  advantages  of  tep-down  design.  By  providing 
definitional  semantics  for  the  operations  this  problem  can 
be  avoided. 

\ 

I 

The  thought  of  providing  rigorous  definitions  for  so 
many  operations  may,  at  first,  seem  a  bit  intimidating. 
Nevertheless,  if  one  is  to  understand  the  refinement  one 
must  know  what  each  operation  means.  The  following 
specification  of  abstract  type  Symboltable  supplies  these 
m<=anings. 
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T^pe  Symbcltable 
Opera  tipr._s : 

INTT:  ->  Sywboltable 

FNTEPPLOCK:  Syinboltable  ->  Symbcltable 
LFAVEEIOCK:  Symbcltable  ->  Symbcltable 

t-CE:  Symbcltable  X  Identifier  X  Attr ibutel ist  ->  Symbcltable 

7INBICCK?:  Symbcltable  X  Identifier  ->  Eoclean 

P.FTRIFVE:  Symbcltable  X  Identifier  ->  At  tribute  list 

Axioms : 

1)  LFAVEBLOCK (INI?)  =  error 

2)  lEAVFELCCK  (ENTEEBLOCK (symtab) )  =  symtab 

3)  LEAVFELOCK  (ADD(£ymtab,id,attrs) )  =  LEAVEELOCK  (sy m tab) 

U)  7INBLCCK?  (INI?r id)  =  false 

5)  7INELOCK?  (FNTFFELOCK  (symt ab) , id)  =  false 

6)  7INELCCK7  (ADD (symtab, id, attrs)  ,id1)  = 

if  7SAMF7  (id , id  1 )  /*  Where  the  definition  of 

7SAME7  is  part  of  the 
specification  of  an  in¬ 
dependently  defined  type 
Identifier  */ 

then  true 

else  7INBLOCK7  (symtab, idl) 

7)  RETRIEVE  (INIT, id)  =  error 

8)  PETPIFVF  (ENTEREICCK  (symtab) , id)  =  RETPIEVE  (symtab, id) 
RETRIEVE (ADD ( sy m t a b , i d , at t rs ) , id1)  = 

if  7SA.ME7  (id  ,  id  1 ) 
then  attrs 

else  PFTP IE VE  (symtab , id  1) 


9) 


-114- 


This  set  of  relations  serves  a  dual  purpose.  Net  only 
dees  it  define  an  abstract  type  that  can  be  used  in  the 
specification  of  various  parts  of  the  compiler,  but  it  also 
provides  a  complete,  self-contained  specification  for  a 
maior  subsystem  of  the  compiler.  If  one  wished  to  delegate 
the  design  and  implemenration  of  the  symbol  table  subsystem, 
the  algebraic  characterization  of  t.he  abstract  type  would 
(unlike  the  informal  description  in,  say,  [KcKeeman  1974]) 
be  a  sufficient  specification  of  the  problem.  In  fact,  the 
decision  procedure  discussed  in  Section  3.6.  can  be  used  to 
formally  prove  the  sufficient-completeness  of  This 
specification . 

The  next  step  in  the  design  process  is  to  further  refine 
type  Symboltable,  i.e.,  to  provide  abstract  implementations 
of  the  operations  of  the  type.  These  implementations  will 
implicitly  furnish  an  abstract  representation  for  values  of 
type  Symboltable.  The  representations  will  make  use  of  the 
abstract  data  types  Sstack  (of  Arrays)  and  Array  (of 
f ttr i butelist s)  as  defined  below. 
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T_y££  Sstack 

Sstack 

Sstack 


NEWSTJiCK: 

PUSH: 

POP: 

TOP: 

7NEWSTACK? 


->  Sstack 
Sstack  X  Array  -> 
Sstack  ->  Sstack 
Sstack  ->  Array 
Sstack  ->  Boolean 


PEPLACE: 


Sstack  X  Array  -> 


Axioms : 

10)  7NEWSTACK?  (NEWSTACK)  =  true 

11)  7NEVJSTACK7  (PUSH  (stk,arr)  )  =  false 

12)  FOP  (NEWSTACK)  =  error 

13)  POP  (PUSH  (stk,arr) )  =  stk 

14)  TOP  (NEWSTACK)  =  error 

15)  TCP  (PUSH  (stk, arr) )  =  arr 

16)  FEPLACE  (stk,arr)  =  if  7NE WSTACK7 (stk) 

;t_ben  error 

else  PUSH  (POP  (stk)  , arr) 


-116- 


Array 

EMPTY:  ->  Array 

.ASSIGN:  Array  X  Identifif^r  X  Attritutelist  ->  Array 

PEAD:  Array  X  Identifier  ->  Attributelist 

7UNDEFINED?:  Array  X  Identifier  ->  Boolean 

Axioms : 

17)  7UNDEFINED? (EMPTY , id)  =  true 

18)  7UNDEFINED? (ASSIGN  (arr, id, attrs) , idl)  = 

if  7SAME7  (id,id 1) 
then  false 

else  7UNCEFINED7  (arr,id1 ) 

19)  PEAD (EMPTY, id)  =  error 

20)  PEAD (ASSIGN (arr, id, artrs) , idl)  = 

if  7SAME7  (id,id1) 

2hen  attrs 

else  PEAD  (ar  r ,  id  1) 

The  general  scheme  of  the  representation  of  type 
Symboltable  is  to  treat  a  value  of  the  type  as  a  sstack  of 
arrays,  where  each  array  contains  the  identifiers  declared 
in  a  single  block.  As  in  Chapter  4,  for  every  function  f  in 
the  more  abstract  domain  (i.e.,  type  Symboltable),  a 
function  f*  is  defined  in  the  lower-level  domain: 
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INIT* :  ->  Sstack 

ENTEPELOCK':  Sstack  ->  Sstack 
LEAVEEIOCK':  Sstack  ->  Sstack 

ADD' :  Sstack  X  Identifier  X  At t riburelist  ->  Ssnack 

7INBLCCK?':  Ssrack  X  Identifier  ->  Boolean 
FETPIEVE':  Sstack  X  Identifier  ->  Attributelist 

The  "code”  for  each  of  these  functions  is: 

INIT'  ::  POSH  (NEWSTACK, EMPTY) 

ENTEPELOCK'  (stk)  ::  PUSH  (stk, EMPTY) 

LEAVEELOCK'  (stk)  ::  if  7NEWSTACK?  (stk) 

then  error 
else  POP  (stk) 

ADD*  (stk, id,attrs)  ::  PEPLACE  (stk , ASSIGN (TOP  (stk)  , id, attrs) ) 

7INBL0CK? '  (Stk, id)  :  : 

if  7NEWSTACK7  (stk) 
then  false 

else  if  7UNDEEINED?  (TOP  (stk) , id) 

/ 

then  false 
else  true 


EETPIEVE'  (stk,id)  :: 

if  7NEWSTACK7  (St k) 
then  error 

il  7UNDEFINED7  (TOP  (stk)  ,id) 
then  RETRIEVE'  (POP  (stk) , id) 
else  READ  (TOP  (stk)  , id) 
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Th®  interpretation  function,  5,  is  defined  by: 

a)  5  (error)  =  error 

b)  $(NEWSTACK)  =  error 

C)  $ (POSH  (stk, EMPTY) )  =  ENTEEELOCK (a  (stk) ) 

d)  5(PDSH  (stk,ASSIGN(arr,id,attrs) ) )  = 

;^.DD  (3  (PUSH  (£tk,arr)  )  ,id,attrs) ) 

Before  continuing  to  refine  these  operations,  i. e. , 
before  supplying  representations  for  types  Queue  and  Sstack, 
let  us  consider  the  problem  of  ascertaining  whether  or  not 
the  above  implementation  of  type  Symboltable  is  correct.  To 
construct  a  proof  of  its  correctness  we  need  only  follow  the 
procedure  outlined  in  Chapter  4.  To  verify  that  the 
implementation  is  consistent  with  axioms  1  through  8  is 
quite  straightforward,  thus  the  proofs  will  not  be  presented 
here.  Axiom  9,  on  the  other  hand,  presents  some  problems 
that  make  the  portion  of  the  proof  pertinent  to  that  axiom 
worth  examining. 

Unlike  the  proofs  in  Chapter  4,  the  proof  that  the 
implementation  satisfies  axiom  9  is  based  upon  an  assumption 
about  -he  environment  in  which  the  operations  of  the  type 
are  to  be  used.  In  effect,  the  assumption  asserts  that  an 
identifier  is  never  added  to  an  empty  symbol  table,  i.e. ,  a 
scope  must  have  been  established  (on  a  more  concrete  level, 
an  array  must  have  been  pushed  onto  the  sstack)  before  an 
identifier  can  be  added.  The  concrete  manifestation  of  this 
assumption  is  formally  expressed: 


-119- 


Assumption  _1 :  For  any  term,  ADD'(X/y/Z),  7NFWSTACK?  (x) 
is  false. 


As  a  corollary  to  this  assumption,  it  is  easy  to  show  (using 
the  definition  of  ADD'  and  axiom  16)  than: 


term,  ADD'(x,y,z), 

7NFWSTACK? (ADD '  (x,y,z) )  is  false. 

The  validity  of  the  above  assumption  can  be  assured  by 
adding  to  the  implementation  of  ADD'  a  check  fcr  this 
condition,  and  having  it  execute  an  ENTEPELOCK  if  necessary. 
This  would  make  it  possible  to  construct  a  completely  self- 
contained  proof  of  the  correctness  of  the  representation. 
In  most  cases ,  however ,  it  would  also  introduce  needless 
inefficiency.  The  compiler  must  somewhere  check  fcr 
mismatched  (i.e.,  extra)  "end"  statements.  Any  check  in 
ADD'  would,  therefore,  be  redundant. 


This  observation  leads  to  a  notion  of  conditional 
correctness,  i.e.,  the  representation  of  the  abstract  type 
is  correct  if  the  enclosing  program  obeys  certain 
constraints.  In  practice,  this  is  often  an  extremely  useful 
notion  of  correctness,  especially  if  the  constraint  is 
easily  checked.  If,  on  the  other  hand,  the  environment  in 
which  the  abstract  type  is  to  be  used  is  unknown  (e.g.,  if 
the  type  is  to  be  included  in  a  library) ,  this  is 
unacceptably  dangerous. 


th  is 


probably 


-120- 


of  Axiom  9: 

Does  PITPIEVE*  (ADD*  (Xry,z)  ,w)  =  if  7SA.ME?  (y,¥) 

then  2 

else  RETRIEVE*  (x,w)  ? 

Consider  first  the  left  hand  side.  Substituting  in  the  imple 
mentation  of  RETRIEVE* 

=  if  7NEWSTACK? (ADD*  (x,y, z) ) 
then  error 

§ls€  if  7UNDEFINED7 (TOP  (ADD*  (x,y  ,Z) )  ,w) 

then  RETRIEVE*  (POP  (ADD*  (x, y,z) )  , w) 
else  READ  (TOP  (ADD*  (x,y,z) )  ,w) 

Which,  applying  the  corollary  to  assumption  1  and  substitutin 
in  the  implementation  of  ADD* , 

-  if  7DNDEEINED? (TOP (PEPLACE(x, ASSIGN  (TOP  (X)  ,Y,Z)  ))  ,w) 

then  RETRIEVE*  (POP  (REPLACE  (x, ASSIGN  (TOF(x)  ,y  ,z)  )  )  ,w) 
else  READ  (TOP  (REPLACE  (x,  ASSIGN  (TOP  (x)  ,y,z)  )  )  ,  w) 
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Which,  by  axiom  16, 

=  if  yUNDFFTNED? (TOP (if  7NEWSTACK? (x) 

then  error 

else  PUSH  (POP  (X)  ,  AS  SIGN  (TCP  (X)  ,y,z)  )  )  ,  w) 

then  EETFIEVF'  (POP  (if  7NEWSTACK?  (x) 

then  error 

else  PUSH  (POP  (X)  ,  AS  SIGN  (TOP  (x)  ,  y  ,z)  )  )  ,  w) 

else  ?EAE(TOP(if  7NFWSTA CK?  (x) 

then  error 

else  PUSH  (POP (X)  , ASSIGN  (TOP (x)  ,y  ,z) )  )  ,w) 
Which,  by  assumption  1  and  axioms  15  and  13, 


=  if  7UNFEFINED7 (ASSIGN  (TOP (X)  , y, z)  ,w) 
then  FETPIEVE»  (POP  (X)  ,w) 
else  READ  (ASSIGN  (TOP  (x)  ,  y,z)  ,  w) 

Which,  applying  axioms  18  and  20, 

=  if  iil  7SAME7(y,w) 
thfn  false 

else  7UNDFFINED?  (TOP (X)  ,w)  ) 

then  RFTPIEVEMPOP  (X)  ,  w) 
else  if  7SAMF7(y,w) 
then  2 


else  PEAD  (TOP  (X)  ,w) 
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Which,  remcvir.g  unreachable  clauses  and  simplifying, 

=  if  ?SAME?(y,w) 

then  7. 

else  if  7UNDFFINED? (TOP (X) ,w) 

then  PETRIEVE*  (POP(x)  ,  w) 
else  PEAD  (TOP  (X)  ,  w) 

Turning  now  to  the  right  hand  side: 

if  7SAME?  (y,w) 
then  2 

else  PETPIEVE' (x,w) 

Substituting  in' the  definition  of  PETPIEVE* 

=  if  7SAHE7(y,w) 
then  2 

else  if  7NEWSTACK7 (X) 
then  error 

else  if  70NDEEINED7 (TOP (X)  , w) 

then  PETPIEVE*  (POP  (X)  ,w) 
else  PEAD  (TOP (X)  ,w) 


Which,  by  assumption  1, 

=  if  7SANE7(y,w) 
then  2 

else  if  7UNDEFINED7 (TOP (X)  ,w) 

then  PETPIEV*"*  (POP  (X)  ,w) 
else  PEAD  (TOP  (X)  ,w) 
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This  is  identical  to  the  expression  to  which  the  left  hand 
side  was  reduced.  Therefore,  given  implementations  of  types 
Sstack  and  Array  that  are  consistent  with  their 
specifications,  the  implementation  of  type  Symbcltable  is 
"correct.”  Assumino  Pl/I-like  based  variables,  poin+ers  and 
structures,  the  implementation  cf  type  Sstack  is  trivial. 
The  basic  scheme  is  to  represent  a  sstack  as  a  pointer  to  a 
list  of  structures  of  the  form: 

1  ,  stk  based , 

2.  val  Array, 

2.  prev  pointer. 

The  operations  may  be  implemented  as  follows: 

NfWSTACK'  ::  null 

PnsH*  (x,y)  ::  proced ure (x : point er , y:Ar ray)  ret urn s  (pointer) 

allocate ( stk)  set  (p) 
p->prev  :=  x 
p->val  :=  y 
return (p) 
end  procedure 

POP’  (x)  ::  procedure (X :pointer)  ret urns  (pointer) 

if  X  =  null 

(‘^rror) 

else  p:=  x->prev 
free  (x->stk) 


return  (p) 
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TOP'  (x)  if  X  =  null 
then  error 
else  x->val 

?NEWST?vcK?'  (X)  ::  X  =  null 

REPLACE '  (X , y)  ::  procedure  (x : pointer, y ; Array)  returns  (pointer) 

if  X  =  null 

return  ( error) 
else  x->val  :=  y 
return  ( x) 
end  £rccedur e 

S  is  defined  by  the  mapping: 

5  (ptr)  =  if  ptr  =  null 

then  NEWSTACK 

else  PUSH (5  (ptr->pre V) ,ptr->val)) 

The  implementation  chosen  for  type  Array  is  a  bit  more 
complicated.  The  basic  scheme  is  to  represent  an  array  as  a 
Pl/I-like  array,  v,  of  n  pointers  to  lists  of  structures  of 
the  form: 

1.  entry  based, 

2.  id  Identifier, 

2.  attributes  Atributelist , 

2.  next  pointer. 

The  correct  element  of  v  is  selected  by  performing  a  hash  cn 
values  of  type  Identifier.  Therefore,  in  addition  to  the 


-125- 


operations  used  in  the  code  above,  the  implementation  of 
type  .Array  uses  an  operation 

HASH:  Identifier  ->  {1,2.. .,n) 

which  is  assumed  to  be  defined  in  the  specification  of  type 
Identifier.  The  "code"  implementing  type  Array  is: 

^iclare  v  (n)  pointer  based 

FMPTY’  ::  procedure  returns  (pointer) 
allocate  (v)  set(vp) 
do  i  :=  1  to  n 

vp->v(i)  :=  null 

end 

return (vp) 
procedure 

-ASSIGN '  (x ,  y ,  z)  :  : 

ttpcedure (x: pointer , y: Identifier ,z :Att ributelist) 
tprurns  (pointer) 

(“^-ty)  ser(vp) 
vp->id  :=  y 
vp->a ttr ibute s  :=  z 
vp->next  :=  x->v  (HASH  (y) ) 
x->v  (HASH  (y) )  :=  vp 

return  (x) 
end  procedure 
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EI^D*  (XrY)  :: 

procedure (x : pointer. v: Tden  tif ier)  returns (Attributelist) 
p  :=  x->v  (HASH  (y)  ) 

Jo  wh^le  (p  #  null  &  -tTSAME?  (p->id,y) ) 
p  :=  p->next 

end 

if  p  =  null 

then  return  (error) 

§ls§  return  (p->at tributes) 
end  procedure 

7DNDEFINED?'  (x,y)  :: 

£Iooedure  (x; pointer . y; Identifier)  returns  (Boolean) 
p  :=  x->v  (HASH(y) ) 

Jo  yhile  (p  -1=  null  &  -iTSAME?  (p->id,  y)  ) 
p  :=  p->next 

end 

(p=null) 

®I1.J  Ef ocedure 

As  one  might  expect,  ®  is  a  bit  more  complex  for  this 
representation.  It  is  defined  using  two  intermediate 
functions:  ffil  to  construct  a  union  over  all  the  entries  in 

the  hash  table,  and  ffi2  to  construct  a  union  over  the 
elements  of  an  individual  bucicet. 
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a)  $(ptr)  =  51  (ptr, EMPTY,  1) 

b)  SI  (ptr ,  arr  ,i)  =  if  ?>?  (i,Ti) 

then  arr 

else  11 (ptr,52(ptr->v(i) ,arr) ,SUCC(i)) 

c)  S2(ptr,arr)  =  if  ptr  =  null 

then  arr 

else  ASSIGN (S2 (ptr->next , arr) ,ptr->id, 
ptr->at tributes) 

The  design  of  the  symbol  table  subsystem  of  the  compiler 
is  now  essentially  complete.  Given  implementations  of  types 
Identifier  and  Attr ibut elist  and  some  obvious  syntactic 
transformations,  the  above  code  could  be  compiled  by  a  PL/I 
compiler.  Before  doing  so,  however,  it  would  be  wise  to 
prove  that  the  implementations  of  types  Sstack  and  Array  are 
consistent  with  the  specifications  of  those  types.  While 
such  a  proof  would  involve  substantial  issues  related  to  the 
general  program  verification  problem  (e.g.,  vis  a  vis  the 
integrity  of  •'-he  pointers  and  the  question  of  modifying 
shared  data  structures),  it  would  not  shed  further  light  on 
the  role  of  abstract  data  types  in.  program  verification,  and 
is  not  presented  in  these  pages. 

5.3.  The  modification  of  algebraic  specifications 

The  ease  with  which  algebraic  specifications  can  be 
adapted  for  different  applications  is  one  of  the  major 
strengths  of  the  technique.  Because  the  relationships  among 
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the  various  operations  appear  explicitly,  the  process  of 
decidinq  which  axioms  must  be  altered  to  effect  a  change  is 
straightforward,  let  us  consider  a  rather  substantial 
change  to  the  language  to  be  compiled.  Assume  that  the 
language  permits  the  inheritance  of  global  variables  only  if 
they  appear  in  a  "knows  list,"  which  lists,  at  block  entry, 
all  ncn-local  variables  to  be  used  within  the  block  [Gannon 
1975],  The  symbol  table  operations  in  a  compiler  for  such  a 
language  would  be  much  like  those  already  discussed.  The 
only  difference  visible  to  parts  of  the  compiler  other  than 
the  symbol  table  cluster  would  be  in  the  ENTEBBLCCK 
operation:  It  would  have  to  be  altered  to  include  an 
argument  of  abstract  type  Knowslist,  Within  the 
specification  of  type  Symboltable,  all  relations,  and  only 
those  relations,  that  explicitly  deal  with  the  ENTEEBLOCK 
operation  would  have  to  be  altered.  An  appropriate  set  of 
axioms  would  be: 


7INBI0CK?  (ENTEEBLOCK (symtab,klist) , id)  =  false 
LEAVEELOCK  (ENTEEBLOCK  (symtab, klist) )  =  symtab 

EETEIEVF  (ENTEEBLOCK (symtab,klist)  , id)  = 
if  ?IN?  (klist, id) 

then  EETEIEVE  (symtab, id) 
else  error 

Note  that  the  above  relations  are  not  well-defined.  The 
undefined  symbol  ?IN?,  an  operation  of  the  abstract  type 
Knowslist,  appears  in  the  third  axiom.  The  solution  to  this 
problem  is  simply  to  add  another  level  to  the  specification 
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by  supplying  an  algebraic  specification  of  the  abstract  type 
Knowslist.  An  appropriate  set  of  operations  might  be: 

CB'EATE:  ->  Knowslist 

APPEND:  Knowslist  X  Identifier  ->  Knowslist 

?IN?:  Knowslist  X  Identifier  ->  Boolean 

These  operations  could  then  be  precisely  defined  by  th<=> 
following  axioms: 

?IN?  (CPBATE)  =  false 

?IN? (APPEND (klist , id)  ,  idl)  = 
if  ?SAME?(id,id1) 
then  true 

else  ?IN? (klisr ,id1) 

The  implementation  of  abstract  type  Knowslist  is 
trivial.  The  changes  necessary  to  adapt  the  previously 
presented  implementation  of  abstract  type  Symboltable  would 
be  more  substantial.  The  kind  of  changes  necessary  can  be 
inferred  from  the  changes  made  to  the  axi omatizat ion . 

While  larger  than  the  typical  "toy”  problem,  the  size  of 
the  above  development  does  not  approach  that  of  today's 
massive  software  projects.  "I  am  faced  with  a  basic  problem 
of  presentation.  What  I  am  really  concerned  about  is  the 
composition  of  large  programs...  For  practical  reasons,  the 
demonstration  programs  must  be  small,  many  times  smaller 
that  the  'life-size'  programs  I  have  in  mind."  [Dijkstra 


1  972  1 
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Fortunately,  there  is  reason  to  believe  that  the 
techniques  demonstrated  will  "scale  up."  The  size  and 
complexity  of  a  specification  at  any  level  of  abstraction 
are  essentially  independent  of  both  the  size  and  complexity 
of  the  system  being  described  and  of  the  amount  of  mechanism 
ultimately  used  in  the  implementation.  The  independence 
springs  in  large  measure  from  the  ability  to  separate  the 
precise  meanina  of  a  complex  abstract  data  type  from  the 
details  involved  in  its  implementation.  It  is  this  ability 
to  be  precise  without  being  detailed  that  encourages  the 
belief  that  the  approach  outlined  here  can  be  applied  even 
to  "very  large"  systems,  and  perhaps  reduce  systems  rhat 
were  formerly  "large"  (i.e.,  incomprehensible)  to  more 
manageable  proportions. 


-131- 


6.  Some  applications,  conclusions,  and  directions  for  future 
resea  rch 

6.1,  J^.ppl  icat  ions 

There  are  four  priirary  areas  in  which  the  algebraic 
specification  cf  abstract  data  types  is  likely  to  prove 
helpful: 

1)  the  specification  and  design  of  software  systeins, 

2)  proofs  of  program  properties, 

3)  project  control  and  management, 

4)  the  testing  of  programs. 

This  section  outlines  the  potential  impact  that  my  approach 
to  the  specification  of  abstract  data  types  may  have  in  each 
of  these  areas. 

As  I  have  suggested  earlier  in  this  thesis,  abstract 
types  can  play  a  vital  role  in  the  formulation  and 
presentation  of  precise  specifications  for  software.  Many 
complex  systems  can  be  viewed  as  instances  of  an  abstract 
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type.  A  data  base  management  system,  for  example,  might  be 
completely  characterized  by  an  algebraic  specification  of 
the  various  operations  available  to  users.  For  those 
systems  that  are  not  easily  totally  characterized  in  terms 
of  algebraic  relations,  the  use  of  algebraic  type 
specifications  to  abstract  various  complex  subsystems  may 
still  make  a  substantial  contribution  to  the  design  process. 
The  process  of  functional  decomposition  requires  some  means 
for  specifying  the  communication  among  the  various  functions 
--  data  often  fulfills  this  need.  The  use  of  algebraic 
specifications  to  provide  abstract  definitions  of  the 
operations  used  to  establish  communication  among  the  various 
functions  may  thus  play  a  significant  role  in  simplifying 
the  process  of  functional  decomposition.  Similarly,  the 
powerful  and  well-defined  operations  provided  by  abstract 
types  may  serve  to  facilitate  the  process  of  functional 
abstraction. 


The  extensive  use  of  algebraic  specifications  of 
abstract  types  may  also  lead  to  better- designed  data 
structures.  The  premature  choice  of  a  storage  structure  and 
set  of  access  routines  is  a  common  cause  of  ine ff iciencies 
in  software.  Because  They  serve  as  the  main  means  of 
communication  among  the  various  components  of  many  systems, 
the  data  structures  are  often  the  first  components  designed. 
Unfortunately,  the  information  required  to  make  an 
intelligent  choice  among  the  various  options  is  often  not 
available  at  this  stage  of  the  design  process.  The  designer 
may,  for  example,  have  poor  insight  into  the  relative 
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frequency  cf  the  various  operations  to  be  performed  on  a 
data  structure.  By  providing  a  representation-free,  yet 
precise,  description  of  the  operations  cn  a  data  structure, 
algebraic  type  definitions  enable  the  designer  tc  delay  the 
moment  at  which  a  storage  structure  must  be  designed  and 
frozen . 

Wany  cf  the  type  specifications  presented  in  this  thesis 
can  be  viewed  as  specification  schemata  defining  classes  of 
abstract  data  types.  Consider,  for  example,  the 
specification  of  abstract  type  Vector  in  Section  4.1.  In  no 
way  does  the  specification  rely  upon  any  properties  of  type 
Item,  thus,  for  all  intents  and  purposes.  Item  is  a  free 
variable  of  type  Type.  Such  specification  schemata  are  in 
many  ways  analogous  to  the  data  structuring  primitives  found 
in  most  modern  programming  languages.  This  suggests  that  a 
library  cf  specification  schemata  might  well  prove  to  be  a 
valuable  tool  in  producing  software. 

The  second  area  in  which  I  expect  the  algebraic 
specification  of  abstract  types  to  have  a  substantial  impact 
is  on  proofs  of  program  properties.  In  a  discussion  of  some 
of  the  major  open  problems  in  program  verification,  London 
[1975a]  states  that,  ”It  remains  to  extend  the  techniques  to 
more  programming  language  constructs,  especially  data 
structures  and  abstractions.  There  is  an  urgent  need  for 
new  specification  languages  for  describing  the  detailed 
intentions  of  programs."  ts  suggested  in  Chapter  4, 
algebraic  type  specifications  represent  a  step  towards 
satisfying  this  need. 
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1+  is  impossible  to  verify  that  a  program  is  truly 
’’correct."  That  is  to  say,  it  is  impossible  to  prove  that  a 
program  actually  fulfills  the  function  that  it  was  intended 
to  perform.  The  best  that  can  be  hoped  for  is  to  prove  that 
a  program  is  consistent  with  seme  formal  specification  of 
objectives. 


For  verifications  of  programs  that  use  abstract  types, 
the  algebraic  specification  of  the  types  used  provides  a  set 
of  powerful  rules  of  inference  that  can  be  used  to 
demonstrate  the  consistency  of  the  program  and  its 
specification.  That  is  to  say,  the  presence  of  axiomatic 
definitions  of  the  abstract  types  provides  a  mechanism  for 
proving  a  program  to  be  consistent  with  its  specifications, 
provided  that  the  implementations  of  the  abstract  operations 
that  i-^  uses  are  consistent  with  their  specifications. 
Thus,  a  technigue  for  factoring  the  proof  is  provided,  for 
the  algebraic  type  definitions  serve  as  the  specification  of 
intent  at  a  lower  level  of  abstraction.  For  proofs  of  the 
correctness  of  representations  cf  abstract  types,  the 
algebraic  specification  provides  exactly  those  assertions 
that  must  be  verified.  The  value  of  having  such  a  set  cf 
assertions  available  should  be  apparent  to  anyone  who  has 
attempted  to  construct,  a  posteriori,  assertions  appropriate 
to  a  correctness  proof  for  a  program. 


Parnas  [1972b]  has  emphasised  the  need 
flow  of  information  among  the  members  cf 
project.  Programmers,  he  argues,  should 
"precisely  the  information  they  need."  In 


to  restrict  the 
a  programming 
have  access  to 
practice,  this 
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means  that  programmers  should  be  given  no  information  about 
the  implementation  of  those  parts  of  the  system  that  are  nor 
their  direct  responsibility.  Brooks  [1975]  takes  issue  with 
this  view.  He  argues  that,  ’’This  presupposes  that  all 
interfaces  are  completely  and  precisely  defined.  While  that 
is  definitely  sound  design,  dependence  upon  its  perfect 
accomplishment  is  a  recipe  for  disaster,” 

-Algebraic  type  specifications  may  be  used  to  provide 
exactly  the  sort  of  interfaces  that  Parnas's  approach 
requires,  thus  helping  to  avoid  the  disaster  prophesied  by 
P  rook  s.  The  formality  of  algebraic  type  specif ic at i cns 
insures  precision,  and,  as  discussed  in  Chapter  3,  there 
exist  techniques  for  verifying  their  completeness  and 
ccnsistency.  Finally,  they  provide  exactly  that  information 
a  programmer  should  need.  An  algebraic  type  specification 
tells  him  how  he  may  use  a  data  object,  that  is  to  say,  what 
operations  are  available  and  what  they  mean,  without  giving 
any  indication  of  the  storage  structure  or  the 
implementation  of  the  operations. 

Given  suitable  restrictions  on  the  form  that 
axiomatizations  may  take,  e.g.,  those  described  in  Secticn 
3.6,  a  system  in  which  implementations  and  algebraic 
specifications  of  abstract  types  are  interchangeable  can  be 
constructed.  In  the  absence  of  an  implementation,  the 
operations  of  the  algebra  may  be  interpreted  symbolically, 
(Husser  and  London  [1975b]  have  used  REDUCE  [Hearn  1971]  to 
implement  just  such  an  interpreter.)  Thus,  except  for  a 
significant  loss  in  efficiency,  the  lack  of  an 
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i  ippl 9 mentation  can  be  made  completely  transparent  to  trie 
user.  Such  a  system  should  prove  valuable  as  a  vehicle  fcr 
facilitating  the  testing  of  software. 

Thouah  systems  have  occasionally  been  designed  in  a  tcr- 
dcwn  fashion ,  they  have  for  the  most  part  been  tested  from 
•^-he  bottom  up.  This  was  necessary  because  the  upper  levels 
could  not  be  easily  tested  in  the  absence  of  an 
implementation  of  lower  levels.  By  eliminating  rhe 
necessity  of  supplying  such  implementations,  this  system 
would  remove  that  inhibition.  It  would  also  lead  to  better 
and  easier  modularization  of  testing.  Much  of  the  need  for 
int^r -programmer  scheduling  would  be  eliminated.  One  would 
rc  longer  need  to  delay  testing  while  awaiting  the 
implementation  of  other  modules.  More  importantly,  if  one 
execu-^es  with  sp-^cif ications  rather  than  implementations  of 
abstract  operations,  the  possible  sources  of  a  known  bug  are 
far  more  limited.  It  should  be  noted  that  in  many  ways  the 
goals  of  this  system  are  closely  related  to  those  outlined 
by  Parnas  in  his  description  of  SODAS  [Parnas  1967].  The 
systems  themselves,  however,  are  quite  different  from  one 
another.  The  most  outstanding  differences  stem  from  th^ 
reliance  of  SODAS  on  operational  specifications  for  those 
operations  that  are  to  be  simulated. 

The  ability  to  use  specifications  for  testing  is  closely 
related  to  the  policy  of  restricted  information  flow 
discussed  above.  If  a  programmer  is  supplied  with  alaebraic 
definitions  of  the  abstract  operations  available  to  him,  and 
forced  to  write  and  test  his  module  with  only  that 
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information  available  to  him,  he  is  denied  the  opportun 
to  rely  intentionally  or  accidentally  upon  information  t 
should  not  be  relied  upon.  This  not  only  serves  to  local 
the  effect  of  implementation  errors,  but  also  to  incre 
the  ease  wi-’-h  which  one  implementation  may  be  replaced 
another.  This  should,  in  general,  serve  to  limit  the  dan 
of  choosing  a  poor  representation  and  becoming  inextrica 
locked  into  it. 


6 . 2.  Conclusi ons 

Hoare's  comment  that  ” 
thought  in  a  way  that  leads, 
understandable  expression  o 
be  called  structured  programm 
as  capturing  the  essence  of  s 
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(which,  given  the  above  defi 
been  called  "good  programming 
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process  of  making  a  series  of  design  decisions.  It  has  long 
b^en  acknowledged  that  the  key  to  good  programming  is  the 
ability  to  reduce  the  amount  of  detail  and  complexity  that 
must  be  considered  in  making  each  decision.  Chapters  1  and 
2  of  this  thesis  argued  that  abstract  da'^a  types  could  serv^^- 
as  a  valuable  aid  in  factoring  th^^  complexity  c^  a 

prouramming  problem.  Chapter  2  also  argued  that  th'=‘  absenct- 
a  sui-*:able  tf^chniaue  ^cr  specifying  abstract  da-^a  *yp's 
was  a  sianificar.*-  harrier  to  “heir  us-=^.  Char-^er  ^  preset 
a  *‘=chninua  *hat  surmrur. '^-S  this  barrier. 


s  up<^- r  1  c  r  i  y  of  this  *‘=-chr.  igue  was  d  e  mcr.  st :  a‘ ►  d 
shewing  that  it  1  a  d s  *•  c 
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(developed  in  Chapter  3)  ur.  derlying  such  a  process  is  non¬ 
trivial.  This  should  not,  however,  diminish  its  utility. 
Just  as  a  programmer  need  no*:  understand  the  theory  of 
parsing  to  use  a  compiler,  h'=  ne-^^d  not  understand  -^he 
t  hGor<=ms  of  Chapter  3  to  make  use  of  a  system  based  upon 
t  hem . 
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piece  of  software  was  demonstrated  by  the  example  in  Chapter 
5.  There  is  no  apparent  reason  why  it  should  not  prove 
useful  in  larger  software  projects  as  well.  Of  course, 
abstract  data  types  are  not  the  solution  to  all  programming 
problems.  No  single  technique  will  suffice  in  all 
situations.  P.  programmer  must  have  at  his  disposal  a 
variety  of  techniques  for  attacking  problems,  and  th<=^ 
technique  espoused  in  this  thesis  is  but  one  of  them. 

The  most  important  attribute  of  any  program  is  that  it 
correctly  accomplishes  the  task  for  which  it  was  intended, 
i.e.,  that  it  fulfills  the  expectations  of  its  users. 
Historically,  programmers  have  relied  principally  upon 
testina  as  a  means  of  demonstrating  the  "correctness”  of 
prcarams.  The  flaw  in  this  approach  has  become  obvious.  A 
program  represents  a  potentially  infinite  set  of 


c  cmpu  tations. 

and  only  a 

small 

s  ubset 

of  these  can  be 

investigated 

by  testing 

.  Test! 

ng 

may 

be  used  to  disprove 

the  theorem  " 

the  program 

works , " 

bu  t 

not 

to  prove  it. 

The  response  to  this  problem  has  been  the  development  of 
formal  "proofs  of  correctness"  which  demonstrate  that  a 
program  exhibits  properties  that  are  invariant  over  all 
executions.  The  algebraic  specification  of  abstract  data 
types  can  play  a  role  in  the  development  of  such  proofs. 
This  role  was  discussed  briefly  in  this  chapter,  and  in  more 
detail  in  Chapter  4,  which  also  demonstrated  its  feasibility 
via  an  example.  Chapter  5  contained  another  example  which 
demonstrated  how  the  use  of  abstract  data  types  could 


use 
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facilitate  the  prccese  of  simultaneously  developing  the 
program  and  the  proof. 

Cespi+e  its  drawbacks,  testing  will,  for  some  time  to 
come,  be  the  principal  means  of  ’’authenticating”  the 
’’correctness”  of  software.  As  suggested  in  Section  6.1.  the 
algebraic  specification  of  abstract  data  types  can  play  a 
significant  role  in  the  testing  of  software,  R.s,c.(E3) 
specifications  should  prove  particularly  useful  since  the 
various  mcnotonicity  reguirements  embodied  in  E3  bound  the 
time  reguired  by  the  simulator  system  to  fully  reduce  terms. 

Before  leaving  this  section,  it  seems  fitting  to  mention 
some  of  the  failings  and  problems  associated  with  the  work 
described  in  this  thesis.  The  value  of  abstraction  in 
general  and  abstraction  of  data  types  in  particular  has  been 
stressed  throughout  this  thesis.  Nevertheless,  the  process 
is  not  without  its  dangers.  It  is  all  too  easy  to  create 
abstrac+ions  that  ignore  crucial  distinctions  or  attributes, 
'’’he  specification  technique  presented  in  this  thesis 
provides  no  mechanism  for  specifying  performance 
constraints,  and  thus  encourages  one  to  ignore  distinctions 
based  on  such  criteria.  In  some  environments  such 
considerations  are  crucial,  and  to  abstract  them  out  can  be 
d isastrous. 

As  suggested  in  Chapter  2,  another  problem  with 
algebraic  specifications  is  that  they  supply  little 
direction  to  implementors.  Only  experience  will  tell  how 
c-asy  it  is  to  go  from  an  algebraic  specification  to  an 
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i  irple  mentation .  It  is  clear,  however,  that  the  transition 
is  less  easy  than  from  an  operational  specification. 

Ky  most  important  reservation  pertains  to  the  ease  with 
which  algebraic  specifications  can  be  constructed  and  read. 
They  should  present  no  problem  to  those  with  formal  training 
in  computer  science.  At  present,  however,  most  people 
involved  in  the  production  of  software  have  no  such 
training.  The  exten*:  to  which  the  techniques  described  in 
this  thesis  are  generally  applicable  is  thus  somewhat  open 
to  coniecture. 


6.3.  Directions  for  future  research 

Throughout  this  thesis  I  have  assiduously  avoided  what 
Section  1,2  identified  as  the  language  design  problem. 
Clearly,  there  is  much  work  to  be  done  investigating  methods 
for  embedding  abstract  data  types  in  the  text  of  programs. 
Closely  rela+ed  to  the  language  design  problem  is  the  task 
of  devising  a  suitable  syntax  for  expressing  algebraic 
specifications.  The  syntax  used  in  this  document,  while 
adequate  (see  theorems  1  and  ,  is  often  inconvenient.  The 
specification  of  error  conditions  can  be  particularly 
awkward.  Consider,  for  example,  the  following  specification 
of  type  Hounded  Stack: 


T_Y£e  Bounded  Stack 


NEW:  In+eoer  ->  Bounded  Stack 


PUSH: 

Bounded 

Stack 

POP: 

Bounded 

Stack 

TOP : 

Hounded 

Stack 

7EMPTY7 : 

Bounded 

Stack 

SIZE: 

Bounded 

Stack 

LIMIT: 

Bounded 

Stack 

X  Item  ->  Bounded  Stack 
->  Bounded  Stack 
->  Item 
->  Boolean 
->  Integer 
->  Integer 


POP  (NEW  (n))  =  error 

POP (PUSH  (s,i) )  =  if  ?EQUAL?  (SIZE (s)  , LIMIT  (s) ) 

then  error 
else  s 

TOP  (NEW  (n))  =  error 

TCP  (PUSH  (s,i)  )  =  if  ZEQUAI?  (SIZE  (s)  , LIMIT  (s)  ) 

then  error 
else  i 

7EMPTY?  (NEW  (n) )  =  true 

?T"MPTY?  (PUSH  (S,i)  )  =  if  7EQUAL?  (SIZE  (s)  , LIMIT  (s)  ) 

then  error 
else  false 

SIZE  (NEW  (n)  )  =  ZEPO 

SIZE (PUSH  (s,i) )  =  if  7EQUAL7  (SIZE  (S)  , LIMIT  (s)  ) 

then  error 

else  SUCC  (SIZE  (s)  ) 

LIMIT  (NEW  (n)  )  =  n 

LIMIT  (PUSH  (s, i) )  =  if  7EQUAL7  (SIZE  (s)  , LIMIT  (s) ) 

then  error 
else  LIMIT  (3) 


It  seems  clear  that  it  would  be  preferable  to  have  some 
shorthand  for  expressing  the  invariant: 

7EQUAL7 (SIZE  (s) , LIMIT  (s) )  implies  that  PUSH  (s, i) =err or . 

Similarly,  it  would  be  useful  to  supply  a  notation  for 
conveniently  specifying  "don't  care"  situations  in  which  the 
specifier  of  the  abstract  type  is  quite  willing  to  let  the 
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i mple m<=nt or  of  the  type  choose,  possibly  from  among  a 
si3ecified  set,  the  value  of  an  operation. 

The  techniques  described  in  this  thesis  should  be  tested 
in  practical  environments  by  attempting  to  apply  the 
methodology  described  to  large  multi-person  software 
projects.  Such  an  experiment  would  be  particularly  valuable 
in  evaluating  both  the  use  of  abstract  data  types  tc  control 
information  flow  among  the  members  of  a  project,  and  the 
test  methodclcgy  suggested  in  Section  6,1,  A  necessary 
prerequisite  to  such  an  experiment  is  the  existence  of 
interacrive  systems  to  aid  in  the  specification  of  abstract 
data  types,  and  to  perform  the  mechanical  simplifications 
involved  in  proofs  of  the  correctness  of  their 
representations.  Fortunately,  systems  that  could  be  easily 
adapted  tc  perform  the  latter  function  already  exist  (e.g,, 
[Good  1974]),  and,  given  the  inference  capabilities  of  such 
a  system,  the  sufficient  conditions  for  sufficient¬ 
completeness  outlined  in  theorem  6  should  lead  directly  to  a 
system  tc  perform  the  former. 
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44  MATCH'^NG  PROOPAf^  AND  DATA  ?  EFRESENTA  "ION  TO  h 
COMPUTING  ENVIRONMENT 

Eric  C,P,  ^-^ehnar,  November  19"'4 
fPh.D.  '"h^'is,  DCS,  1Q74] 

45  THREE  A'np^nACHES  TO  DELIA  ELE  SOETWA.FE;  LANGUAGE 
DESIGN,  DYADIC  SPECIFICATION ,  COMPLEMENTARY  S.EMANTTCS 
J.E.  Donahue,  J.u.  Gannon,  J.V.  Gu^-^ag  and 

J.J.  Horning,  Dpcamber  1974 

46  THE  SYNTHFS^S  OF  ORTIM.AL  DECISION  TREES  Fpnv 
DECISION  TAPIRS 

Halmu*  Schumacher,  December  19'^4 
fM.Sc.  T basic,  DCS,  197U] 

47  languagf  Design  ”^0  fnha-.ncf  progpammtng  rfliapit  T'^y 
vTohn  E.  Gannon,  January  1°75 

[Ph.D.  Th--cic,  DCS,  197^] 

4P  DETE  PMI  NIS'^IC  LEFT  TO  FIGHT  PARSING 

Christopher  J.M.  Turnbull,  January  1975 
[Ph.D.  Th^ais,  EE,  1974  ■] 

4Q  A  NETWORK  FppMrwQpfr  POF  RELATIONAL  I MPL  EM  FN  TA '^T  ON 
D.  Tsichrinzis,  Eabruary  1975 

50  A  UNIF'^Fp  APPROACH  *^0  FTTNC'^IONAL  DFPPNDENCIES 
AND  PELATIPiNc 

P.A.  Bernstein,  J.R.  Fye-nson  and  p.C.  Tsichri^zis 
F-^brnary  1975 

5  1  ZETA:  A  PROTO'I’YPE  RELATIONAL  DATA  E.ASE 

management  system 

M.  Prodi=  f-d).  Fcbrua.ry  1U75 

52  automatic  GFNmprTICN  OF  S YNTAY-^mpAI RIMg  AND 
PARAGFAPHTNG  PAFSEFS 
David  T.  Parnard,  March  1975 
[M.Sc.  '^h^sis,  DCS,  197D] 

OUEPY  EYECUTTCN  ?NP  index  SELECTION  FOR  d  n  a'^IO  NA  T. 

DA'^A  EASES 

J.H.  Gill-s  Parlay  and  Stewart  .A.  Schustar,  March  1975 
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CSRG-S4  AN  ANNOTAT’^D  T>T  ELIO  GPAP  FY  ON  CONPII'^SR 
PPOGPAN  ENGINEEPI-NG 

J.V.  Gu^>aq  (od.)»  Third  Edition,  April  1975 


CSPG-55  STPnCTnPKD  SPESFTS  OF  THF  PL/1  LANGUAGE 

Richard  C.  Holt,  and  David  R.  Wortman,  ^  ay  1975 

C5PG-56  F.F,^,TUPES  Of  A  CONCEPTUAL  SCH^'^A 
D,  Tcichritzis,  June  197*^ 

CSPG-57  HEFLIN:  TOWARDS  AN  IDFA.I  PPOGRANMING  LANGUAGE 
Eric  C.P.  Hohnor,  July  1975 

CSRG-58  ON  THE  SD'^ANTICS  OF  THE  RELATIONAL  DA^A  NODEL 
Hans  Ailhort  Schmid  and  J.  Richard  Swanson, 

July  197P  r  Procoedin gs  of  the  SIGNOD 

Confsroncf=,  1975  ] 

CSRG-59  THF  SP’^CIFTCa’^iON  AND  APPLICATION  tq 
PFOGPA’^'^ING  OF  AT^STFACT  DATA  TYPES 
John  V.  Gu*:‘^aa,  S-^pt amber  19^5 
rPh.D.  Thesis,  DCS,  1975] 


